Elite: Dangerous

https://www.youtube.com/watch?v=d_pUyaMo0fY

Hey, ein Bericht über Elite: Dangerous und nach all den Jahren einmal überwiegend gute Nachrichten. Scheint so, als würde sich das Spiel ohne Braben erholen und weiter entwickeln.

Nachdem ich meinen Spielerechner auf Win 10 gedowngraded habe geht ja auch die VR Brille wieder.

Vielleicht sollte ich mal gucken.

Liebe Touristen, bitte gebt uns eine Chance

Brandenburger Pension beklagt Ausbleiben von Gästen nach AfD-Wahlerfolgen

https://archive.is/e2bVL

und weiter

Ja, ein großer Teil der Prignitzer Bevölkerung hat die AfD gewählt, aber die Mehrheit unserer Mitbürger wünscht sich ein demokratisches und tolerantes Miteinander, damit wir alle von dem guten wirtschaftlichen Weg, den unsere Stadt in den letzten Jahren eingeschlagen hat, profitieren. Dazu trägt der Tourismus in unserer Region einen großen Teil bei.

Das stimmt.

Aber mein Stream ist auch voll von Meldungen über Trupps von Vermummten, die mit Messern und Latten und Baseballschlägern Leute aufs Korn nehmen, die gleichgeschlechtlich Händchen halten, bunte Haare haben oder sonstwie nicht in spießbürgerliche Schubladen passen.

Und die gerne Urlaub machen möchten ohne sich krankenhausreif schlagen zu lassen.

Und da helfen keine Apelle, das ist wie Terror wirkt.

Not being federated and E2E as an advantage

https://revolt.chat/ is a chat that ultimately tries to emulate and displace Discord as an alternative.

Revolt is not E2E encrypted and not federated. That is a big plus.

Federation and E2E encryption are features that make an implementation much, much more complicated without need. Most people do not want to organize a women's shelter or abortion support or the antifash resistance. They just want to have a public guild server for their gaming guild or chat about 3D printers.

Don't federate chat

Having a federated system for that has a number of implications that make implementations more complicated and impact quality of life for users.

In a federated systems, different servers can be on different versions of the server software. This can impact features, which may or may not work properly. If will affect security of the whole network due to lack of patches in one place. And it will create propagation delays of messages inside the federated network, that is, order or even availability of messages can differ depending on what server in the federated network you are on.

As a consequence for the individual user, there is no single history order of messages – some messages may be missing, appear out of order, and there will be spam. Lots of it.

Back when Google Hangouts was still federating XMPP (Jabber) servers, specialized Jabber server implementations existed with the sole purpose of simulating user profiles, discovering Hangouts that are joinable, and spamming users with, well, garbage.

Operating a public chat room in 2025 is already a moderation nightmare. Adding federation is a surefire way to make things fail.

Federate identity, multihome clients.

This is not to say that the client should be bound to a single server.

It can, and should, in fact, connect to different servers for each community. The server, though, should be a "single visible instance, single history for all" thing, and have proper controls for the moderation team to control admission of new users to whatever their policy is.

EDIT: And, obviously, federated identity can be quite useful.

In fact, even Mastodon and other Fediverse systems should use federated identity, and also be identity servers. This will allow me to connect my client to a chat server without making any new account.

Don't E2E encrypt chat

Use TLS (or even a REST protocol over HTTPS) to connect to the chat server. But do not E2E messages.

Keep a clear text history on the server.

This makes it trivial for a single identity ("isotopp") to have multiple devices (desktop, ipad and web client) and switch between them, yet have the same chat history on all devices.

It will allow new users to join a channel and see the full channel history, if the channel is configured to do that (and because the server is not federated, the channel backlog policy can actually be enforced).

It makes it trivial to implement search and indexed archives for a server that wants that.

It makes it easier to implement detection of spammy behavior, implement rate limits, and to autodetect inappropriate or banned content.

With E2E, the server only has binary garbage that it cannot read itself, only distribute. It may not even have metadata.

It will be complicated to scan messages for spammy behavior, detect banned content.

It will be impossible to provide backlog to newly joined users. An existing identity (Isotopp) adding a new device (his phone) can only have backlog, if the other clients (the desktop of ipad client of Isotopp) of that user support client-to-client backlog transfer.

Without E2E encryption, there is no keysplit problem ("half a channel only sees undecipherable messages"), there is no "known plaintext" problem to handle, and there is no large-scale key distribution problem.

Conclusion

That is, a project that

• uses TLS, but not E2E, and
• that uses multi-homed clients but not federation,

will be able to build a better client with better UX with less effort and be a lot more agile.

Both properties (federation, E2E) do little for the end user experience except in a few limited use-cases, but come with a huge cost in implementation complexity, review and anti-abuse measures that will ultimately bind the majority of your dev capacity for nothing in return.