Summary
Implement the submissions inbox pattern described in PLAN.md Section 3.1: a protocol path with `$recordLimit` and proof-of-work that allows non-role-holders to submit data (e.g., bug reports from anonymous users) without opening the protocol to unrestricted writes.
Context
PLAN.md lines 99–101 describe this pattern as a way to accept controlled writes from external actors while maintaining the "everyone owns their namespace" principle. Currently, all write paths require role-based authorization. This limits scenarios like:
- Anonymous bug reports to a public repo
- Unsolicited patch submissions from users without contributor roles
- Feature requests from the community
Design
structure: {
submission: {
\$recordLimit: 100,
\$proofOfWork: { difficulty: 18, algorithm: 'sha256' }
}
}
The submitter computes a proof-of-work hash before the DWN accepts the record. The record limit caps total submissions. The repo owner can promote submissions to first-class issues/patches.
Notes
- Proof-of-work validation may require DWN SDK support (`$proofOfWork` directive)
- Check DWN SDK for `$recordLimit` support status
- This is a defense-in-depth measure against spam, complementing the existing role model
Summary
Implement the submissions inbox pattern described in PLAN.md Section 3.1: a protocol path with `$recordLimit` and proof-of-work that allows non-role-holders to submit data (e.g., bug reports from anonymous users) without opening the protocol to unrestricted writes.
Context
PLAN.md lines 99–101 describe this pattern as a way to accept controlled writes from external actors while maintaining the "everyone owns their namespace" principle. Currently, all write paths require role-based authorization. This limits scenarios like:
Design
The submitter computes a proof-of-work hash before the DWN accepts the record. The record limit caps total submissions. The repo owner can promote submissions to first-class issues/patches.
Notes