The past few days I’ve been thinking about the chatmail way of “anybody can register” and its implications and basically I’ve come at the conclusion that maybe the logical next step is going away from federation and into better multi-accounts management ?
If an account I want to talk to is on a platform and I can easily create an account there then I might as well create an account and start conversation. I might have as many accounts as I have contacts. This is where working on the client is important because it is where this disparity should be made transparent (all I care about is talking to X or Y). When that is done federation isn’t needed anymore because accounts don’t need to talk “across” instances.
In a way this is what IRC has been about: an account exists on a network, the same person on another network will have another identity. Nostr also has something similar: messages are being exchanged through a router but routers don’t talk to each other. The difference of course is that the same message can be sent through multiple routers and the receiver just has to hope at least one has it.
This is a good thing to reduce linkability between people and conversations. In fact SimpleX has something not far from that (to talk to someone you have to send a message to their server, but for them to reply to you they have to talk to your server; both might be different). Is that something worth thinking about or just useless rambling ?
Definitely an interesting idea! Right now, I don’t think it gives enough advantages to warrant the big implementation effort, if we would want to make this work nicely.
Creating multiple accounts on multiple servers, and reducing linkability, is definitely something we’re aiming for, though, but without giving up on federation completely:
With the IRC model, if the server hosting the group goes down, chatting can’t continue. With federation, only some users have to look for a different server.
Without federation, your chat partner could easily find out your IP address by inviting you to their server, and then logging the IP address.
The phone would have to keep a lot of open connections to different servers, if many chat partners are on different instances.
I am horrified by this idea, and if it happened I would certainly stop using the resulting service.
So I should explain that very strong statement.
We have more than enough centralised platforms. Sooner or later, they all suffer platform decay and become awful places to be, but we keep using them anyway because of the social trap effect; you can’t leave Facebook because everyone else is there.
Open standards-based federation and lots of little servers and clients is the thing protecting Deltachat from this fate. I don’t want to use anything provided by someone else if I may not be able to leave, easily and at low social cost.
In another Freenode IRC mess, the hostile platform might be a bit more competently evil, and act more gradually and effectively hinder departures. Freenode failed partly because the affected people were devs and had other communications channels. Deltachat users would be easier to trap.
Also, Deltachat is good for circumvention of censorship because messages are just yet another encrypted e-mail, and any e-mail host could be used. Centralization would make it easier to block.
But maybe I have completely misunderstood you.
And of course single-use metaaccounts could be made with redundant communications channels, so the failures of a single server provider couldn’t cut social connections. I am not in the least opposed to single-use accounts.
In case I wasn’t clear, I am not of course advocating for single-use accounts and centralization, quite the contrary. My idea is smaller, more numerous IRC servers, one for each room: joining doesn’t need an account and your identity in two rooms is unlinkable.
Hocuri’s answer convinced me that it is not as valuable as I thought because the impact of a server being down is too high
Ah, then I think we agree on centralization. A server going sorta down due to a hostile takeover or utterly down due to a hardware failure are actually similar problems.
I think when I talk of single-use email accounts, you talk of unlinkable identities. It’s good to have them available.
Rotate the accounts along with the keys, retaining redundancy. An interesting idea. Accounts with a residence time would be awkward for the friend that emails a decade or two after they last wrote, though; some people would want stable addresses too. Should addresses come with an expiry date, optionally set to “indefinite”?
