@onlytina kommt halt ganz drauf an, wievirl Vorerfahrung du mit Linux hast...
Und welche Aufgaben du erledigt haben willst...
ich hab 2007 umgestellt, und bin immer noch nicht ganz fertig 😁😁😁
Und welche Aufgaben du erledigt haben willst...
ich hab 2007 umgestellt, und bin immer noch nicht ganz fertig 😁😁😁
@kuketzblog ich verachte all die seitenbetreiber mit ihren cookiebannern, die nicht der dsgvo entsprechen... test.de gehört dazu.
scheiß dark pattern
scheiß dark pattern
@z428 Ich hab ein wenig weiterrecherchiert.
Im XMPP-Raum über Freie Messenger wurde wieder einmal Matrix vs. XMPP diskutiert... Ich weiß, dass wir hier schon ein Stück weiter sind in der Diskussion... :)
Da es aber die von uns angedachten Lösungen noch nicht gibt, müssen wir noch mit dem bestehenden Weiterarbeiten...
Die große Kritik an Matrix ist ja der Ressourcenhunger durch die föderierten Räume. Matrix macht es immer, XMPP kann es gar nicht.
Wie wir festgestellt hatten, wären die föderierten Räume für einen P2P-Messenger aber eine Grundvoraussetzung, oder zumindest eine sehr gute Idee, damit Message-Zwischenspeicherung möglich ist, wenn ein Client einmal offline ist.
Es gibt anscheinend eine XEP für XMPP, welche diese föderierten MUCs beschreibt, und im MUC über Freie Messenger meinte einer, dass dies nur noch niemand umgesetzt hat, weil es keinen Bedarf dafür gäbe...
Ich fand gestern das:
https://www.isode.com/products/m-link-constrained-networks.html
Isode ist offenbar ein Anbieter für militärische Kommunikation, und der hat die federated MUCs in seinem XMPP-Server schon umgesetzt.
Der Grund ist, dass bei langsamen, instabilen Leitungen mit geringer Bandbreite schnell die Grenzen der Übertragung erreicht werden, wenn in einem MUC die Updates an jeden einzelnen Client gesendet werden, bzw. wenn eine Crew auf einem Schiff Tagelang gar keine Verbindung hat, können die Crewmitglieder nicht mal untereinander chatten... da ja die Verbindung zum Server mit dem MUC nicht vorhanden ist.
Wenn Räume jetzt föderiert auf mehreren Servern vorhanden sind, dann muss von Server zu Server (also die instabile, langsame Verbindung) ein MUC-Update nur ein einziges Mal zum anderen Server gesendet werden, und nicht mehr zu jedem einzelnen Client selbst. Und im Falle der Nicht-Erreichbarkeit können die lokalen User weiter den MUC nutzen und bei nächster Gelegenheit wird die Kommunikation nachgesynct...
Dieses militärische Szenario gilt natürlich auch für die zivile Schifffahrt (z.B. auf einem Kreuzfahrtschiff...), aber auch für daheim selbst auf einem Raspi gehostete XMPP-Server, der immer wieder mal vom Netz geht. Z.B. wenn ich im Urlaub daheim alle Geräte vom Strom nehme... Bei mir gehostete MUC wären dann für die anderen Teilnehmer nicht mehr verfügbar... mit föderierten MUC aber schon.
Es müsste halt nur konfigurierbar sein, welche MUC föderieren sollen, und welche nicht. Sowohl in XMPP als auch bei Matrix. Und nicht föderierte MUC müssen aber trotzdem von außen zugänglich bleiben (was bei XMPP ja geht, bei Matrix anscheinend aber nicht).
Im XMPP-Raum über Freie Messenger wurde wieder einmal Matrix vs. XMPP diskutiert... Ich weiß, dass wir hier schon ein Stück weiter sind in der Diskussion... :)
Da es aber die von uns angedachten Lösungen noch nicht gibt, müssen wir noch mit dem bestehenden Weiterarbeiten...
Die große Kritik an Matrix ist ja der Ressourcenhunger durch die föderierten Räume. Matrix macht es immer, XMPP kann es gar nicht.
Wie wir festgestellt hatten, wären die föderierten Räume für einen P2P-Messenger aber eine Grundvoraussetzung, oder zumindest eine sehr gute Idee, damit Message-Zwischenspeicherung möglich ist, wenn ein Client einmal offline ist.
Es gibt anscheinend eine XEP für XMPP, welche diese föderierten MUCs beschreibt, und im MUC über Freie Messenger meinte einer, dass dies nur noch niemand umgesetzt hat, weil es keinen Bedarf dafür gäbe...
Ich fand gestern das:
https://www.isode.com/products/m-link-constrained-networks.html
Isode ist offenbar ein Anbieter für militärische Kommunikation, und der hat die federated MUCs in seinem XMPP-Server schon umgesetzt.
Der Grund ist, dass bei langsamen, instabilen Leitungen mit geringer Bandbreite schnell die Grenzen der Übertragung erreicht werden, wenn in einem MUC die Updates an jeden einzelnen Client gesendet werden, bzw. wenn eine Crew auf einem Schiff Tagelang gar keine Verbindung hat, können die Crewmitglieder nicht mal untereinander chatten... da ja die Verbindung zum Server mit dem MUC nicht vorhanden ist.
Wenn Räume jetzt föderiert auf mehreren Servern vorhanden sind, dann muss von Server zu Server (also die instabile, langsame Verbindung) ein MUC-Update nur ein einziges Mal zum anderen Server gesendet werden, und nicht mehr zu jedem einzelnen Client selbst. Und im Falle der Nicht-Erreichbarkeit können die lokalen User weiter den MUC nutzen und bei nächster Gelegenheit wird die Kommunikation nachgesynct...
Dieses militärische Szenario gilt natürlich auch für die zivile Schifffahrt (z.B. auf einem Kreuzfahrtschiff...), aber auch für daheim selbst auf einem Raspi gehostete XMPP-Server, der immer wieder mal vom Netz geht. Z.B. wenn ich im Urlaub daheim alle Geräte vom Strom nehme... Bei mir gehostete MUC wären dann für die anderen Teilnehmer nicht mehr verfügbar... mit föderierten MUC aber schon.
Es müsste halt nur konfigurierbar sein, welche MUC föderieren sollen, und welche nicht. Sowohl in XMPP als auch bei Matrix. Und nicht föderierte MUC müssen aber trotzdem von außen zugänglich bleiben (was bei XMPP ja geht, bei Matrix anscheinend aber nicht).
@medixtub ach und ich dachte, in wirklich schweren notfällen bringt man einen patienten zu den experten auf die facebook-timeline...
Seit Monatn bin ich das erste Mal wieder in Wien und mit den Öffis unterwegs...
Waren da früher auch schon so viele Idioten unterwegs?
Waren da früher auch schon so viele Idioten unterwegs?
Yeah! "NOYB.eu übermittelt heute mehr als 500 Beschwerden an Unternehmen, die auf ihrer Webseite rechtswidrige Cookie-Banner verwenden – ... die größte Beschwerdewelle seit dem Inkrafttreten der DSGVO vor drei Jahren." https://noyb.eu/de/noyb-setzt-dem-cookie-banner-wahnsinn-ein-ende
@foreverxml but i'm dreaming of an activitypub-driven federation for gitea-software, to host my own server, and cn do pull-requests to forked repos on other servers... @codeberg
@foreverxml im on codeberg since a few month.
have only to transfer my guthub repos, and delete them afterwards...
#needsometime
@codeberg
have only to transfer my guthub repos, and delete them afterwards...
#needsometime
@codeberg
@keyoxide sure. i tried it with gajim.
but there is no "about-section" in vcard. and i can edit it.
asked also in gajim xmpp-grouo, and they told me, there is no about-section in vcard-definition at all...
@hbenjamin
but there is no "about-section" in vcard. and i can edit it.
asked also in gajim xmpp-grouo, and they told me, there is no about-section in vcard-definition at all...
@hbenjamin
@hbenjamin yes. it looks nice.
but the howto for xmpp does not work.
there is no "about-section" in vcard... @keyoxide
but the howto for xmpp does not work.
there is no "about-section" in vcard... @keyoxide