DIP-285 Follower notification and visibility

[wesbiggs]

Abstract

It is currently possible for Alice to know who follows her content in DSNP if and only if both of the following occur:

1. The follower stores the relationship in the unencrypted publicFollows user data item
2. Alice or her agent scans the publicFollows lists for the entire set of DSNP User Ids (and maintains this as it changes)

We would like Alice to be able to see who follows her, even if the follower is using privateFollows.
In the Ecosystem Architecture Working Group, Dave Clark has called this a "discreet follow".
This aligns with the way many existing online social networks work.

It is also useful for Alice to be able to be informed when there is an addition to (or subtraction from) the set of users who follow her.
It should be possible to do this without excessive computational overhead.

Proposed solution as follows:

1. New Follower Notification Announcement that can alert Alice to a change in who is following her. Alice should be able to determine the follower's identity, but an outside observer should not (if the follow is "private"). Ideally, however, an outside observer should at least be able to count how many followers Alice has.
2. New User Data type privateFollowsPRIds that functions similarly to privateConnectionPRIds for private follows. The nature of the PRId means only the controller of the PRId (Bob) and the target of the relationship (Alice) can view the relationship.

Rejected design:

• The Notification Announcement could have a field with Bob's User Id (concatenated with a random nonce to avoid chosen plaintext attacks), encrypted with Alice's public key. Alice would be able to decrypt this, but to outside observers it would be indistinguishable from random data. This suits Alice but it does not give outside observers the ability to tell if the value represents an actual User Id, so Alice could abuse this and claim to have as many followers as she wants by generating random data.

Proposed design:

• Alice designates a service endpoint that will issue a followerId that is deterministic but distinct for each user who wants to follow Alice. Outside observers can verify whether a given followerId maps to a real DSNP user, and count distinct followerIds for Alice to determine her follower count.
• Each followerId has an associated key pair. Bob can request his followerId for Alice and the associated key pair. Third parties can request the public key for a given followerId for Alice. Using the secret key, Bob can sign a message and include it in the notification announcement such that an outside observer can prove that only someone in possession of the secret key for a followerId has signed the message.

It is still possible that Alice's service is dishonest, and will issue announcements for users who haven't actually chosen to follow Alice (or not issue deterministic followerIds). Services therefore need to be identified and have an associated reputation. A service implemented via a threshold network could provide a generally trustless alternative.

Motivation

We think the ability for Alice to see who is following her is important, even if those relationships are not meant to be fully public. This enables creators to engage with their audience in more meaningful ways.

There are analogues to "purely private" following in some social networks, such as the ability to follow a curated list of users on X.
Here we stray into the realm of opinion on what makes for a healthy ecosystem, and what elements are core to preserving an interoperable social graph.
It would be possible to use privateFollows without requiring a privateFollowsPRIds entry for each user followed (false negative). This would allow Bob to follow Alice without Alice being aware. We should decide if this "allowable" behavior in spec terms.

It is also possible for Bob (with the help of his provider) to "lie" about following Alice (false positive), by creating a privateFollowsPRIds entry (and Notification Announcement) without a corresponding privateFollows entry. This seems unlikely to be particularly useful to either Bob or Alice, so may be an acceptable edge case.

In general, we think that providing these facilities, and SDKs/libraries that take this approach, will allow for intended outcomes.

Specification Pull Request

TBD

Rationale

This approach seems logical given the requirements and constraints.

We want to maintain data sovereignty, and writing a reverse mapping to the consensus system would violate the principle of data control. Bob should only be able to change Bob's state, not Alice's.

We want to keep as much data as possible "off-chain" (so it does not need to be maintained by the consensus system). The Announcement model shifts notification data to off-chain batch files, and thus requires parsing by interested observers. Providers that do not have Alice's keyAgreement private key will only be able to maintain counts, and might choose to simply ignore this data as they do not have a user-provider relationship with Alice. If Alice decides to switch providers, the new provider may need to rebuild the follower list from past Notification Announcements. An alternative design would be to have Alice listen for Notification Announcements and maintain something like privateFollowers (a set of GraphEdge objects for each follower). This could be done with or without Bob maintaining a privateFollowsPRIds entry. Having both would allow for cross-checking but require more on-chain storage. If we put this in economic terms, we would be making Alice pay for storage based on the number of people who choose to follow her (something that Alice may desire, but ultimately does not control).

See discussion above on rejected design for followerIds.

Backwards Compatibility

Users that have published privateFollows but do not have any privateFollowsPRIds would not be visible to the followed user until this is updated. A provider could do that the next time the user requests an update to their graph, as a just-in-time process, but a more proactive approach would be useful for rapid migration.

Reference Implementation and/or Tests

To fully maintain the follower list for Alice, a system that has access to Alice's keyAgreement public key needs to monitor all Follow Notification Announcements with Alice as the followed person. This becomes a
What could this look like implemented or what tests could be provided to assist in validation of implementations?

Security Considerations

The security of this scheme depends on multiple factors.

1. Is Alice's agent trustworthy?
2. Does Alice's agent keep followerId-related private keys secure? Can Bob only access a follower private key by authenticating? Is the authentication process secure?

There are additional challenges around time-based analysis.
If Bob puts the Alice->Bob PRId in his privateFollowsPRIds, and then immediately (via his delegated provider) creates an allegedly pseudonymous Follower Notification Announcement, outside observers may be able to correlate the relationship at least with a statistical confidence factor.
To remedy this, as a heuristic, providers can introduce a randomized delay before publishing the notification. The length of the delay should be relative to the number of similar notifications published during a specific time window. The DSNP batching mechanism alone may be sufficient.

Dependencies

None known.

References

TBD

Copyright

Copyright and related rights waived via CC0.