[maxtaco]

This would be a great application for us! We are not exactly there yet, for reasons of privacy. Right now, there is no way for alice@host to allow unauthenticated users to view her profile. But we can definitely allow this on a host-by-host basis. With this small change, I think your application fits very naturally.

I wonder, what sort of interface is right for you? A library to compile against or a CLI app to shell out to? If a library, which languages?

[raphinou]

Interesting! We're at a very early stage of the implementation and develop in rust. We aim to provide multi-sig capabilities, as defined in a JSON file where the public keys of the signers can be found. If a signer looses a key, we want this 'signers' file to be updatable with the new key. We decided that signers can be humans of processes, so the keys are not an identity of a person, which might be an important detail. Currently, to update a signers file, other members of the multi-sig must sign the update. This works fine, but we are early enough in the project implementation to explore other approaches, hence my question.

We'd rather not shell out to a cli, and would preferably go with a lib or rest interface.

[maxtaco]

An attack that might be of concern with this configuration is the server suppressing updates to this JSON file, or showing different versions of the JSON file to different clients. What you're describing is pretty close to what FOKS is getting at with signature chains and Merkle Trees, but maybe it's overkill for this particular application.

I wonder if the policy you describe could be implemented as world-visible team with world-visible users. Others have commented on the need for something like this, so I think it should be pursued with high priority. What's slighlty fuzzy to me is how these totally world-viewable teams and users would interact with more closed-down users on other servers.