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
This project aims to identify things "in a network", and for the most part focuses on the TCP/IP networking stack, but extends into the IPFS network and Onion/Tor network too.
But I don't see a means to indicate content to be looked up on a blockchain? IPFS content has a lot of usage with blockchain-based projects, and if there were reflexive ways for referring back to blockchain-based data, I think that would be very helpful.
Similar to how the main README gives examples of /http/example.com/index.html and /tls/sni/example.com/http/example.com/index.html for accessing web content (not just connecting to the web server that controls the content), I believe the following for blockchain-related content would fit that pattern:
This proposal puts the chain ID first, which makes this different than ERC4804 in the ordering of the address parts, but the other logic of turning functions into path parts from ERC4804 could apply here too.
The text was updated successfully, but these errors were encountered:
This project aims to identify things "in a network", and for the most part focuses on the TCP/IP networking stack, but extends into the IPFS network and Onion/Tor network too.
But I don't see a means to indicate content to be looked up on a blockchain? IPFS content has a lot of usage with blockchain-based projects, and if there were reflexive ways for referring back to blockchain-based data, I think that would be very helpful.
Similar to how the main README gives examples of
/http/example.com/index.html
and/tls/sni/example.com/http/example.com/index.html
for accessing web content (not just connecting to the web server that controls the content), I believe the following for blockchain-related content would fit that pattern:This proposal puts the chain ID first, which makes this different than ERC4804 in the ordering of the address parts, but the other logic of turning functions into path parts from ERC4804 could apply here too.
The text was updated successfully, but these errors were encountered: