This is an aggregated list of the known issues that were mentioned in the Discord thread, should probably be moved to or in parallel with issues on the spec repo eventually.
design for user → device revocation for compromised or unused device identities
device presence notifications. This is needed for efficient MLS commit acks (the online device at the lowest index in a given ratchet tree level can only know it has the lowest index if it knows what other devices are available), file transfer (device filters the list of peers it polls for files by presence), as well as being a generally nice-to-have social feature.
We already have transient messages in the spec for read receipts and typing indicators, so adding presence indicators would be trivial. I’ll squeeze it in during the refactor.
Few other things I remember that need to be added to the spec:
A dedicated page giving a quick outline of the two bots we’ll need:
Moderation Bot
Storage Bot
Explaining how the Storage bot fits into the File handling part of the spec
The file availability group extension
How we might want to handle “commit storms” where too many devices try to commit to the group state at once
Also the ACK system we discussed for sanity testing commits before we apply them
I think a more principled solution to commit storms would encompass this as well (the problems are related in the sense that both maliciously broken commits and ambiguously ordered commits necessitate the same sort of collective sanity checking/consensus)
IMO we should add a simple flag somewhere that indicates that a user identity is a bot and that’s it. Part of the reason I like the approach to files we came up with is that the “storage server” is just a normal user at the spec level with special configuration/software client side and a device with a high uptime. A group is still perfectly functional without a storage bot, just some devices may not be able to access files because no peers are up and willing to relay them.
tl;dr bots “going in the user hole” is A Good Thing, Actually because it keeps complexity down.
We should absolutely mention moderation and storage bots in non-normative/ecosystem overview documentation though, (little bit of a tangent but these would be great candidates for example projects to teach the core library with, once we get it working)
Yup yup, that was the plan once I finished the spec refactor. I was gonna add a isBotflag to the UserIdentity struct.
That’s actually a better idea than having them in the spec. Maybe I’ll just mention the possibility in passing when documenting the isBot flag and link to the ecosystem doc once we have that going.