Verified mentions

ActivityPub
1

It would be really neat if mentions in a post could somehow be verified.

For example, consider this social graph:

  • Alice blocks Brun
  • Cassandra follows Brun

Then, consider the events:

  1. Brun makes a post mentioning Alice
  2. Brun’s post gets pushed to Cassandra’s instance
  3. Cassandra’s instance asks Alice’s instance about the post/mention
  4. Alice’s instance checks that the post is real, and contains the mentioned user. (N.B. this single-handedly prevents leaking someone’s entire blocklist, but quickly exposes persistent harassers.)
  5. Alice’s instance returns a status based on whether Alice blocks Brun (or her instance).
  6. If this result is okay, the mention gets linked, and composing a reply will also carry the mention.

This would genuinely cut down on harassment by a lot. Thoughts?

3 Likes
2

I think it’s a good idea. :+1:

Now, how I would implement it. The advantage of this approach is that Cassandra’s instance doesn’t need to ask Alice’s instance about the mention. Cassandra’s instance can verify the claim, and thus it will be clear that Brun’s instance is making an invalid mention (and thus it can be hidden).

By using cryptography and FEP-8b32, I could imagine a signed Mention like

{
   "type": "Mention",
   "attributedTo": "https://abel.example/alice",
   "name": "@bob",
   "href": "https://banach.example/bob",
    "proof": {
         "type": "DataIntegrityProof",
         "controller": "https://abel.example/alice",
         "created": "2024-02-23T19:10:00Z",
         ...
    }
}

By having some rules on the age of verifications of Mentions, one should be able to ensure that this algorithm provides the protection one wants.

The biggest question, in need of an answer for me, would be to determine a good mechanism for Bob requesting Alice’s actor, i.e. a proxy, to sign the mention. I can even imagine that one gives the user the choice between:

  • Anybody can mention me (except blocks).
  • Only my followers / following can mention me (probably with a caveat to allow replies)
  • Approve all mentions manually
3

We suppose we’ll have to see how ppl decide to implement it, if anyone does.

We can imagine 4 levels of verified mentions:

  1. None: Status quo, neither verify nor support the appropriate mechanism
  2. Supported: The local instance does not verify mentions but the appropriate mechanism is supported
  3. Checked: The local instance verifies verified mentions, regular mentions are still allowed
  4. Enforced: The local instance verifies verified mentions, regular mentions are not allowed

These levels work pretty well in a non-crypto solution. Can a crypto solution provide similar functionality?

4

Yes and no. The functionality will be different on a technical level, but should have the same user facing behavior.

I have drawn a helpful diagram:

Untitled-2024-02-24-0911

I think it illustrates the major difference:

  • With Crypto: Burt can ask Alice for permission to mention her. Then he gets a permission slip, i.e. the signed Mention, and communicates it to Cassandra
  • With a classic, no-crypto, approach Cassandra needs to ask Alice if Burt had permission to mention her.

One needs cryptography here to have the means to create permission slips. The advantage of this approach becomes clear if one thinks of having many Cassandras. So if one has 100 Cassandras:

  • Crypto: Burt sends 1 request to Alice, Burt sends 100 requests, one to each Cassandra. Cassandra uses her cache to verify the signature.
  • Classic: Burt sends 100 requests, one to each Cassandra. Alice receives 100 requests, one from each Cassandra.

This means we have reduced the load for Alice by a factor 100!!!

5

Could / should this be extended to boosts/announces?

  1. Bert makes a post mentioning Alice
  2. Cassandra boosts Bert’s post
  3. Dave receives Cassandra’s boost
  4. Dave’s instance verifies whether or not Bert was allowed to mention Alice

In this scenario, the “classic” and “crypto” cases behave differently depending on whether Alice blocked Bert before or after step 1.

1 Like
6

we don’t care for the load factor, honestly. more importantly, how can alice enforce “mentions must be signed” with a level 2 instance.

the crypto solution would allow unsigned mentions, but not broken signatures? why would the harasser bother to sign them, then? the non-crypto solution doesn’t differentiate between “unsigned mentions” and “broken signatures”, it just knows about (any) mentions.

further, if an instance that doesn’t support verified mentions (level 0) wants to mention an user that does, the non-crypto solution still works, while the crypto solution would break all mentions.