DIP-289 Permissioning of replies/respondents

[wesbiggs]

Abstract

Provide a facility for authors of a Broadcast to proactively moderate its Replies. (This proposal is complementary to DIP-286 Content Moderation Announcement, which discusses reactive moderation of replies.)

Each Broadcast is considered a permissioned space, controlled by the author of the Broadcast.

Proposal

Announcement structure

• Each Broadcast Announcement may contain an authorizationPublicKey
• Each Reply Announcement in a thread which has an authorizationPublicKey must include an authorizationSignature over a well-defined set of fields from the Reply
• If and only if the authorizationSignature is verified, the Reply should be considered valid and shown in the thread.

This means that each time Bob wants to reply to a permissioned Broadcast from Alice, he must ask Alice, or her agent, for permission to do so. We therefore need to introduce a new concept into DSNP of an Authorization endpoint.

We propose that Alice can designate an Authorization endpoint. If Bob wants to post a reply, Bob must request an authorizationSignature from the endpoint. The authorization may be synchronous (an immediate approval or denial) or asynchronous (Alice wants to screen the replies, say).

Endpoint Discovery

• Alice designates a HTTPS URL and publishes it in her profile. (We add an extension property to AS note.

Endpoint API:

This endpoint works as follows:

Input:

• inReplyTo link to thread position (could be a Reply or a Broadcast)
• respondentKey of Broadcast for which a signature is requested
• url and contentHash of proposed reply Note
• senderId of respondent (Bob's MSA)
• User Id, public key and signature of respondent agent (e.g. their Provider)
• optional(?) callbackUrl for asynchronous response handling

Output:

• 200 OK with a signature in the response OR
• 403 Forbidden to indicate immediate denial OR
• 202 Accepted; expect a callback later

The callback, if used, will echo back the input parameters and contain the OK/Forbidden status, and a signature if OK.

Questions:

• Should permissioning also apply to Reaction Announcements in the thread?
• Should permissioning also apply to reposting of the broadcast (work in progress; see DIP-290)? Reposting of replies?
• How can Alice describe who can reply? This is important so that apps don't frustrate users by allowing them to compose a reply, only to see it rejected. This could be a free text property within the Note, or a well-defined taxonomy of rules (that might grow over time, but would need to be interpretable by the application).

Motivation

Many forms or rulesets for user control over a thread require a mechanism for the author's proactive approval.

Examples:

• User blocking (defined as preventing Bob from participating in Alice's threads)
• Only Alice's approved followers can reply
• Only Alice's friends, or friends of friends, can reply
• Only accredited medical professionals can reply
• Alice will screen each reply and decide if it should be posted

Specification Pull Request

TBD

Rationale

This approach allows the rule-based behavior behind Alice's strategy for permissioning to be very flexible.
Applications displaying the thread don't have to know why a Reply was approved, merely that it is.

Backwards Compatibility

Any proposal that breaks compatibility with previous versions must describe how the change will be implemented and handle the migration period.

Reference Implementation and/or Tests

What could this look like implemented or what tests could be provided to assist in validation of implementations?

Security Considerations

Any change will effect the security of the system in some way. Describe the implications this DIP on security, both technical and human.

Dependencies

• List of dependent DIPs if any.

References

Any references or other related links that might be helpful.

Copyright

Copyright and related rights waived via CC0.