DIP-289 Permissioning of replies/respondents

[wesbiggs]

Abstract

Provide a facility for authors of a Broadcast to proactively moderate its Replies.

Each Broadcast is considered a permissioned space. This is necessary if user blocking (defined as preventing Bob from participating in Alice's threads) is allowed.

Proposal:

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

This means that each time Bob wants to reply to a 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).

(More detail to come here)

Questions:

• Should permissioning also apply to Reaction Announcements in the thread?
• Should permissioning also apply to reposting of the broadcast (work in progress; see separate DIP)? Reposting of replies?

Motivation

Answer the question of why? What problem does this solve? Who might care?

Specification Pull Request

Current change pull request:

Rationale

Why were the design choices made? What other solutions were rejected and why?

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.