[itsibitzi]

On spam:

We’ve got some basic filtering for full on DoS type attacks already.

The difficulty here is that a user can produce a reasonable amount of spam from a spread of IP addresses which would be disruptive to our journalist users but below threshold to be considered a DoS attack.

It’s tricky because we can’t have anything that could link a given message to a given user as that would break anonymity.

We’ve got some ideas with anonymous credentials from app attentions for the more long term. E.g. if you’re expected to submit 1 message an hour from your queue you can request 24 single use tokens from the API by performing an attestation that you’re running a genuine app. You then spend these as you send messages. We don’t have a full spec for this right now such that it can be fully anonymous but that’s the general idea.

There’s also some possible spam detection we can do in the journalist GUI which we’re interested in exploring. Right now the spam control is quite basic (muting) but the message rate is low due to the threshold mixer anyways so not so bad.

On key management:

Each journalist has an encrypted vault which requires a key derived from a password. If this password is lost and the journalist has no backup then it’s game over. We need to regenerate their identity in the key hierarchy as if they were a new user and messages they’ve not seen are lost, there is no way to pick up those sources again.

We have some plans on using MLS as an inter-journalist protocol which should enable having multiple actual humans per journalist/desk listed in the app. That would depend on the journalists agreeing to have their vault be shared of course. Once multiple humans are backing a single vault then the risk of password loss becomes smaller as if one journalist loses their password the other journalist should be able to share their back messages to them.