You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Similarly to the Postal Service for Swarm (PSS), event-based messaging feature could be provided by leveraging Single Owner Chunks (SOC) which would offer lesser resource intensive messaging between two peers. There should be a new API endpoint that provides a websocket for relaying incoming SOC payload.
Motivation
PSS messaging mines Content Addressed Chunk (CAC) to the recipient's neighborhood.
The default mine requirement is bucketDepth (16 bits matching in the recipient's overlay address). On each trial, the Bee client incrementing a nonce and building up the BMT on the chunk to check this criteria.
Therefore, this leads to many hash operations and many trials for the successful mining for the sender, moreover, it puts the burden on the recipient to try to "open" all incoming chunks as a PSS message. This feature is usually blocked on gateways as well because of potential DOS attack.
One could send messages to the recipient in the same SOC several times with the same mutable postage batch where the recipient would mine the identifier based on the sender's Ethereum address used for their SOC and start listening on new messages. This mined identifier could be shared in a specific consensual feed of the recipient that the sender could read.
By this, sender does not have to mine message and recipient does not have to scan all chunks for messages.
The mining of the identifier is much faster than mining CAC.
Implementation
GET gsoc/subscribe/{socAddress}
where the socAddress is the calculated address from the mined identifier and the sender's Ethereum address and it should fall within the recipient's neighborhood.
Drawbacks
The text was updated successfully, but these errors were encountered:
Summary
Similarly to the Postal Service for Swarm (PSS), event-based messaging feature could be provided by leveraging Single Owner Chunks (SOC) which would offer lesser resource intensive messaging between two peers. There should be a new API endpoint that provides a websocket for relaying incoming SOC payload.
Motivation
PSS messaging mines Content Addressed Chunk (CAC) to the recipient's neighborhood.
The default mine requirement is
bucketDepth
(16 bits matching in the recipient's overlay address). On each trial, the Bee client incrementing a nonce and building up the BMT on the chunk to check this criteria.Therefore, this leads to many hash operations and many trials for the successful mining for the sender, moreover, it puts the burden on the recipient to try to "open" all incoming chunks as a PSS message. This feature is usually blocked on gateways as well because of potential DOS attack.
One could send messages to the recipient in the same SOC several times with the same mutable postage batch where the recipient would mine the identifier based on the sender's Ethereum address used for their SOC and start listening on new messages. This mined identifier could be shared in a specific consensual feed of the recipient that the sender could read.
By this, sender does not have to mine message and recipient does not have to scan all chunks for messages.
The mining of the identifier is much faster than mining CAC.
Implementation
GET gsoc/subscribe/{socAddress}
where the
socAddress
is the calculated address from the mined identifier and the sender's Ethereum address and it should fall within the recipient's neighborhood.Drawbacks
The text was updated successfully, but these errors were encountered: