[4FBB09]
5225225@furry.engineer
e2ee chat design principles for what it's working on, some apply outside of that, feel free to challenge/ask for elaboration
- identity key fingerprints in usernames. don't make your server a CA
- rooms being distributed between servers would be nice, but is a really hard problem. don't bother for now
- likewise, federation isn't relevant. talk directly to the servers you need to, proxied.
- the server component that has to work, handling messages, should be as small scope as possible. non-critical stuff(media) goes on a different server, possibly even unrelated(sender-chosen)
- unauthenticated group message send/fetches. leave it up to the e2ee to filter out messages from non-members, ratelimit if needed. this reduces metadata stored
- message deletion/history on join is a per-group decision, "e2ee but you get a day of past history on join" is better than plaintext
- control over who can message you/join is important when identities are cheap and servers can't see content or moderate. "invite links" only?
2
0
0
Charlotte 
/Cinny 
charlotte
@5225225 eh i think having user-selectable usernames that then map to a cryptographic identity is the way to go for identity
i think for like larger chats (or ones that are like tied to a specific project or sth) should be stuck on a server with some replicas, dms and small group chats should be p2p
1
0
0
[4FBB09]
5225225@furry.engineer@charlotte mhm. i don't like how much people just ignore key resets/don't verify in the first place though. if no one cares then the e2ee is opportunistic
"if you lose your keys or your device gets compromised that account is dead" sucks though, yeah. key loss can be mitigated by encrypted backups, key compromise.... can't, really.
2
0
1
Charlotte /Cinny
charlotte
@5225225 i guess it’s a difference between “typical average user” and “privacy nerd”
i think it could be feasible to have both. imagine if the identity provider is a single document which contains a sticky “don’t allow any rerolled keys” that is then published on relay/server transparency logs for example
1
0
0
[4FBB09]
5225225@furry.engineer@charlotte you wouldn't even need that, just have "pubkey:[hash]" as an identity type, alongside "server:[url]". where a pubkey needs you to prove ownership of that key, and server trusts that one server(with key transparency to limit badness)
though unsolved problem: migrating identities? to a different server? that would make compromise fatal again, unless you let old servers overrule new ones(in which case, you can't migrate from a server you don't trust)
0
0
1
☀️
k, cis iirc
kouhai@treehouse.systems@5225225 @charlotte mildly worried about metadata and third party risk here:
> non-critical stuff(media) goes on a different server, possibly even unrelated(sender-chosen)
1
0
0
@kouhai @charlotte i'm assuming that you have an anonymous (proxied through some dedicated proxy server protocol, tor, Something Else) connection to servers. (clients will likely enforce this).
that has to be true anyways, because of the "you connect directly to message servers" thing, so in general it has to be safe for you to connect to servers you didn't explicitly "want" to connect to.
but the risk from "you connect to a server from a "clean" IP, fetch an encrypted blob, and verify the hash and decrypt it" is minimal to where i'm comfortable with that
plus, it allows redundancy in file hosting, and lets servers that don't want to take on the uptime responsibility of "you must not go down or people can't send messages" to be file hosts.
0
0
0
polyproto federation protocol
@polyproto @ShadowJonathan feel free to poke it in dms for clarification, this was golfed to fit within the 1024 char limit of this instance so is vague on impl details
0
0
0