@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?
@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
@z428 da hast du natürlich vollkommen recht. Wieder einmal :)
Und ich denke - zumindest für mich ist es so - dass wir hier einen Punkt gefunden haben, wo man einen Hebel ansetzen kann. Das sind für mich gerade wesentliche Teile im Puzzle, die ich in der Diskussion mit dir finden durfte.
Vielen Dank dafür!!
Und ich denke - zumindest für mich ist es so - dass wir hier einen Punkt gefunden haben, wo man einen Hebel ansetzen kann. Das sind für mich gerade wesentliche Teile im Puzzle, die ich in der Diskussion mit dir finden durfte.
Vielen Dank dafür!!
@XR_Nuernberg_sunny2 @s4f_le ich hab leider keinerlei erfahrung in der organisation von solchen massenevents...
aber ich würd unheimlich gerne so eine aktion mit den fahrgästen wie ich sie weiter oben geschildert habe, eineiner region ausprobieren...
ist in meiner wohngemeinde zum glück nicht notwendig, da ich hier alle halbe stunde einen schnellen zug nach wien und dazwischen noch je eine langsamere S-Bahn habe, und das von 4 in der Früh bis um Mitternacht...
Aber ich kenne genügend gegenden, wo es hoch an der Zeit wäre!
gerade jetzt, wo wien das Parkpickerl flächendeckend einführt und die Umlandgemeinden medienwirksam "fürchten, zum Parkplatz von Wien zu werden"...
JETZT wäre der ZEitpunkt da, sowas zu organisieren!
aber ich würd unheimlich gerne so eine aktion mit den fahrgästen wie ich sie weiter oben geschildert habe, eineiner region ausprobieren...
ist in meiner wohngemeinde zum glück nicht notwendig, da ich hier alle halbe stunde einen schnellen zug nach wien und dazwischen noch je eine langsamere S-Bahn habe, und das von 4 in der Früh bis um Mitternacht...
Aber ich kenne genügend gegenden, wo es hoch an der Zeit wäre!
gerade jetzt, wo wien das Parkpickerl flächendeckend einführt und die Umlandgemeinden medienwirksam "fürchten, zum Parkplatz von Wien zu werden"...
JETZT wäre der ZEitpunkt da, sowas zu organisieren!
Der Standard lässt Tracking seiner User zu
Ich habe den Standard - als eine der wenigen vertrauenswürdigen journalistischen Quellen in Österreich - im pur-Abo online abonniert, da ich keine Werbung und kein Usertracking will.
Jetzt hab ich nach und nach 3rd-Party-Sources aus meinem Browser verbannt (uBlock-Origin. user.js-Spielereien), und es ist nicht einmal mehr der Login-Button auf der Website zu sehen. Gebe ich die Quellen frei, ist ein Login aber nicht mehr möglich.
Der Standard verwendet also Techniken, die ein Login ohne 3rd-Party-Quellen gar nicht mehr ermöglichen...
Bin jetzt im Austausch mit dem Support und ernte den Berühmten Autobus-Blick "Wos wüll er?"
Unverständnis, Unsensibilität und Unkenntnis brechen nur so hervor...
eine von mehreren Antworten vom Standard Kundendienst auf meine Hinweise:
"...vielen Dank für Ihre Nachricht und Ihr Interesse an unserem Medium.
Für die Anmeldung auf derStandard.at ist es notwendig, dass Sie in Ihrem Browser Cookies zulassen, da die Webseite ohne Cookies nicht funktioniert – es handelt sich bei diesen Cookies um rein funktionale, für den Betrieb der Webseite notwendige Cookies, die kein Daten-Tracking oder Userdaten beinhalten."
als ob es bloß "Cookies" wären, die tracken und verfolgen...
Ich kündige nach mehrmaligem Mail-Wechsel nun mein Abo. Ich bezahl nicht dafür, dass ich dann erst recht getracked werde.
Jetzt hab ich nach und nach 3rd-Party-Sources aus meinem Browser verbannt (uBlock-Origin. user.js-Spielereien), und es ist nicht einmal mehr der Login-Button auf der Website zu sehen. Gebe ich die Quellen frei, ist ein Login aber nicht mehr möglich.
Der Standard verwendet also Techniken, die ein Login ohne 3rd-Party-Quellen gar nicht mehr ermöglichen...
Bin jetzt im Austausch mit dem Support und ernte den Berühmten Autobus-Blick "Wos wüll er?"
Unverständnis, Unsensibilität und Unkenntnis brechen nur so hervor...
eine von mehreren Antworten vom Standard Kundendienst auf meine Hinweise:
"...vielen Dank für Ihre Nachricht und Ihr Interesse an unserem Medium.
Für die Anmeldung auf derStandard.at ist es notwendig, dass Sie in Ihrem Browser Cookies zulassen, da die Webseite ohne Cookies nicht funktioniert – es handelt sich bei diesen Cookies um rein funktionale, für den Betrieb der Webseite notwendige Cookies, die kein Daten-Tracking oder Userdaten beinhalten."
als ob es bloß "Cookies" wären, die tracken und verfolgen...
Ich kündige nach mehrmaligem Mail-Wechsel nun mein Abo. Ich bezahl nicht dafür, dass ich dann erst recht getracked werde.