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:
- The follower stores the relationship in the
privateFollowPRIds user data item
- Alice or her agent scans the
privateFollowPRIds 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 or storage overhead.
This proposal is to add a new Follower Notification Announcement with the following requirements:
When Bob follows Alice,
- Ecosystem participants can be alerted to changes in the count of Alice's set of followers (additions and removals).
- Alice can determine each follower's identity.
- An outside observer cannot determine that Bob was the user who followed Alice.
- An outside observer can verify Alice's claimed follower count.
- Alice can choose not to recognize Bob in her follower count (a "block" signal).
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 (Alice may desire a high follower count, but ultimately she does not control this).
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
TBD
Security Considerations
There are 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 #296.
References
TBD
Copyright
Copyright and related rights waived via CC0.
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:
privateFollowPRIdsuser data itemprivateFollowPRIdslists 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 or storage overhead.
This proposal is to add a new Follower Notification Announcement with the following requirements:
When Bob follows Alice,
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 aprivateFollowsPRIdsentry. 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 (Alice may desire a high follower count, but ultimately she does not control this).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
TBD
Security Considerations
There are 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 #296.
References
TBD
Copyright
Copyright and related rights waived via CC0.