Conversation
Introduces the Mined Owner Chunk (MOC) concept for efficient notifications in Swarm architecture, detailing specifications, rationale, and implementation notes.
zelig
changed the title
zelig
changed the title
|
@copilot provide description |
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
|
very interesting. it would indeed be very good. could the current protocol support the polling? i foresee maybe scaling issues as service nodes would have to maintain many more connections to consumer nodes, perhaps something that could be mitigated by providing nodes with incentive to do so and some balancing defacto by per-node limits or otherwise more specific maybe one for the good problems to have bucket that, though. bring it on! ( : |
|
Well, }I dont think any extra connections will be needed at all. Instead nodes will try to use any of their already established connections (to create a MIC/MOC address) neighbourhood |
|
dependencies: |
There was a problem hiding this comment.
🟡 Changes recommended
The new SWIP document has multiple front-matter convention issues and numerous typos/malformed markup/incomplete lines that should be corrected before merging.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Pull request overview
Adds a new Draft SWIP (SWIP-42) describing “Mined Owner Chunks (MOCs)” as a mechanism to support more efficient/robust notification delivery in the Swarm ecosystem.
Changes:
- Introduces a new SWIP-42 markdown document outlining MOC/MIC concepts and a high-level API outline.
- Adds initial rationale sections (premineable/content-neutral/encryption/async deliverability) and discussion of undermining/non-local recipient considerations.
File summaries
| File | Description |
|---|---|
| SWIPs/swip-MOC.md | New Draft SWIP-42 document defining MOCs/MICs and motivating their use for notifications. |
Review details
- Files reviewed: 1/1 changed files
- Comments generated: 10
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| author: Bálint Újvári <@bosi95>, Viktor Tron <@zelig> | ||
| discussions-to: https://discord.com/channels/799027393297514537/1239813439136993280 | ||
| status: Draft | ||
| type: <Standards Track (Core)> | ||
| created: 2025-11-04 |
| @@ -0,0 +1,132 @@ | |||
| --- | |||
| SWIP: 42 | |||
| Mined Owner Chunks are Single Owner Chunks (SOC) with a fixed part (ID or owner) and an ephemeral part | ||
| (owner or ID) mined so that the SOC address falls into a particular target neighbouhood. This SwIP | ||
| introduces the concept as a vehicle for robust _notifications_. The properqooo e ooogg g vejggggqe |
| - Target neighbourhood: indentified by an overlay prefix specified similar to nonce mining. | ||
| - Target neighbourhood overlay prefix: | ||
| - Mined owner: | ||
| - Mined ID: |
|
|
||
| ## Rationale | ||
|
|
||
| The rationale behind this n |
|
|
||
| The rationale behind this n | ||
|
|
||
| ### Premineble |
| 1. $D_s<=m<d$ -- in this case the recipient is in the same neighbourhood, or | ||
| 1. $m<D_s$ -- recipient is not even in the same neighbourhood as the overlay prefix |
| The recipient can afford syncronising only the PO bins $d'>=d$ of any of the full nodes in the appropriate target NH | ||
| the neighbourhood. |
| #### Privacy | ||
| Importantly, this allows any neighbourhood to serve as a proxy while recipients to be located basically anywhere in the network and still efficiently get the nessages delivered to them in their PO bin $m$. From the proxy nodes' perspective, if $m<<D_s$, then the fact that a node external to their neighbourhood syncs part of their reserve can easily reveal them as the recipient (even though this information is private to the parties and also deniable by $R$). | ||
|
|
||
| ## Implementatiom notes |
| ## Backard compatibility | ||
|
|
||
| ## testing |
No description provided.