so how do I - have encrypted group state - with permission (role-/user based) overrides - where permission overrides and other metadata are not known to the server - but the group state is stored on the server in an encrypted manner
@star i mean like. adding tons of complexity in state synchronization that then results in all sorts of fun times and a chat app that'll randomly refuse to serve its primary purpose of sending messages
@zaire@illyBytes probably sadly out of scope though. but would be cool. maybe someone makes a polyproto extension at some point that does this. a little metadata leakage is fine as a treat /hj
@star@illyBytes soatok has been a bit icky for me largely due to the relentless signal-shillery which i can somewhat see the reasoning for but is nontheless annoying
@illyBytes@star as for the linked blogpost: if you think about it, if you're working with spaces that are either public or big enough to be trivially infiltrated by an adversary, e2ee won't really make them all that much safer, will it? e2ee only does anything for you as long as you don't simply let the adversary enter your chat. even if you're looking at this from the perspective of a server operator, i don't think an adversary would stand much to gain from pressuring you about the messages that pass through that they couldn't by just joining the public spaces. if the cops want to force a server to mandate self-doxxing they could do that regardless of any encryption
@zaire@illyBytes What I really want is optional encryption for guild channels. Because I absolutely agree, in that, if the guild reaches a certain size or popularity, E2EE in popular channels is sort of useless. But: For friends' guilds, for closed collectives; things like that: I do think it is really, really nice. That, and group DMs + DMs in general.
@star@illyBytes to have the option for similarly encrypted private channels in guilds makes sense, but theres probably just not much to be gained in practice from trying to keep the server unaware of the permissions, might as well cut that corner if that means avoiding matrix syndrome
@zaire@illyBytes i think this can be done pretty nicely without having "matrix syndrome". but it would take a lot of time to develop and would also not add that much to the finished product that it can safely be considered out-of-scope.
@star@amazonawaws.com
