Abstract
We propose eliminating the publicFollows user data type in order to better ensure user privacy and remove confusion over the interplay of public and private follow lists.
To allow a user to enable a user that they are following to know that fact, we propose adding privateFollowPRIds (pseudonymous relationship identifiers).
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.
This proposal does not specifically address the way a followed user can be notified of a follow or unfollow event.
That affordance is the subject of a separate proposal.
We must add a new PRId Context to the table; Context 1 for Follows with Context String PRIdCtx1.
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. While this cannot be technically prevented under this design, we should make it mandatory for spec compliance.
It is also technically 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.
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. DSNP systems will need to determine their own specific migration approaches.
Reference Implementation and/or Tests
TBD
Security Considerations
Bob must grant a new user data write permission for privateFollowPRIds to the relevant agents that will maintain this data on his behalf. There are no fundamental changes to the DSNP security model.
Dependencies
None known.
References
TBD
Copyright
Copyright and related rights waived via CC0.
Abstract
We propose eliminating the
publicFollowsuser data type in order to better ensure user privacy and remove confusion over the interplay of public and private follow lists.To allow a user to enable a user that they are following to know that fact, we propose adding
privateFollowPRIds(pseudonymous relationship identifiers).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.
This proposal does not specifically address the way a followed user can be notified of a follow or unfollow event.
That affordance is the subject of a separate proposal.
We must add a new PRId Context to the table; Context
1forFollowswith Context StringPRIdCtx1.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
privateFollowswithout requiring aprivateFollowsPRIdsentry for each user followed (false negative). This would allow Bob to follow Alice without Alice being aware. While this cannot be technically prevented under this design, we should make it mandatory for spec compliance.It is also technically possible for Bob (with the help of his provider) to "lie" about following Alice (false positive), by creating a
privateFollowsPRIdsentry (and Notification Announcement) without a correspondingprivateFollowsentry. 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.
Backwards Compatibility
Users that have published
privateFollowsbut do not have anyprivateFollowsPRIdswould 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. DSNP systems will need to determine their own specific migration approaches.Reference Implementation and/or Tests
TBD
Security Considerations
Bob must grant a new user data write permission for
privateFollowPRIdsto the relevant agents that will maintain this data on his behalf. There are no fundamental changes to the DSNP security model.Dependencies
None known.
References
TBD
Copyright
Copyright and related rights waived via CC0.