DIP-285 Follower notifications

[wesbiggs]

Abstract

Assuming the implementation of #296, it will be 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 privateFollowPRId user data item
2. Alice or her agent scans the privateFollowPRId lists for the entire set of DSNP User Ids (and maintains this as any user's data changes)

This approach has scalability challenges. It is 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.

This proposal is to add a 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. Ideally, however, an outside observer should at least be able to count how many followers Alice has.

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. It is also important for the attention economy for followership to be countable.

Specification Pull Request

TBD

Rationale

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

Retrospective announcements should be issued once this functionality is available in order for third parties to accurately count followership.

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 an important ecosystem service.

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

Relates to, but does not depend on, #296.

References

TBD

Copyright

Copyright and related rights waived via CC0.