If anyone knows more about this, please give your assessment.
Discussion
The link appears broken (from noStrudel).
There are problems with nostrudel and note references on and on 😞, this one works:
Is this what youz are talking about?
https://github.com/PurpleI2P/i2pd/releases/tag/2.50.2
#i2pd #Reticulum
Yup. Up to 256-bit random hash is a large enough address space we don't have to care/think about address clashes when different networks are bridged
Kids (re-)discovering distributed systems engineering, part 357.
Anyone any idea on why this nevent1 is broken on nostr-tools? it works on `nak`.
`nak decode nevent1qqsr3n57p07s736jmp8ct82hz92y080g9rglt63qrj4edg4pd7vpt3gpp4mhxue69uhkummn9ekx7mqzgq6rve3kv93kge3exqmrgv3nxscnyvnxvycrsvrxx4jrjetxxcun2denvsmnjvfsxsux2vrzxg6nvd3nxpnrsctxxgunvvenx93rvefhntdeca`
`require('nostr-tools').nip19.decode('nevent1qqsr3n57p07s736jmp8ct82hz92y080g9rglt63qrj4edg4pd7vpt3gpp4mhxue69uhkummn9ekx7mqzgq6rve3kv93kge3exqmrgv3nxscnyvnxvycrsvrxx4jrjetxxcun2denvsmnjvfsxsux2vrzxg6nvd3nxpnrsctxxgunvvenx93rvefhntdeca')`
Uncaught Error: TLV 2 should be 32 bytes
Anyone attempting distributed systems engineering:
This just came up on Hacker News
https://replica-io.dev/blog/2024/03/04/on-implementation-of-distributed-prtocols
Woefully superficial and incomplete survey of attempts at distributed systems.
But should still do the job of discouraging 99% of everyone that endeavors to do so to drop everything and abandon this particular ship. Chances are you're not cut out to do it.
Forget "AI", *this* is the hardest challenge in computer science today. It separates the wheat from the chaff for good and you're probably chaff.
Yeah, that would work.
Public addresses are only really needed so that the entire network can discover the nodes on the rest of it. If you're only interested in connecting to a subset of nodes, or not interested in the global network at all, you don't really need a protocol like IP. Something like what you're talking about would be cool.
Think about what a protocol is fundamentally: a piece of information known to pertinent parties that enables them to interact in ways defined by the protocol. It's just a set of rules we both know so that we know how to find each other, how to understand each other, how to interpret each others behavior, etc. A handshake, a language, names, interaction can't really exist without protocols, and interaction is defined by protocols. So a protocol has to be thought out for it's uses, what you're describing is a fantastic idea, but it can't replace TCP/IP, primarily because of discovery, nodes must be known to each other already, who someone is is part of the protocol, not part of the information being communicated.
What I described was a replacement of IP. If you think it is "great" but "doesn't replace IP" then you must have misread it.
Relative addressing doesn't allow for discovery. Discovery requires an announce or probing, it is interactive. Knowing a router is connected to another router would be a part of the protocol and would be rigid. Bad failure mode there.
Again, if you're on a network where you know who your peers are it would work. Some protocol that allows for a node to determine the likelihood that another node exists, such as a scheme that allows for the identifier to describe something about the node, would help discover nodes faster without having to know it exists. When you're on a network where you don't know anything about the network without asking first, arbitrary identifiers like IP are ideal. It helps with discovery if the address space is limited. But if you want some addressing scheme that is relative, address space is not limited, and the address doesn't describe anything about the node you'll get fragmentation and no better than random discovery, like randomly discovering a bitcoin address. If you don't care what node you connect to that can work for some cases, but usually we care who we are talking to.
Form follows function, what are you trying to do? Form dictates function, a design decision not strictly directed at a problem you're trying to solve will lead to unintended outcomes. If you want to do what IP does, just use IP. If you want some other type of network topology or node behavior then think about how you want the network to work and design based on that. Your idea is cool and would be useful, but it isn't IP and wouldn't work the same as IP.
Discovery is in the last paragraph of my proposal. Nodes announce themselves and their connections. Big registries calculate routes on behalf of other nodes.
Re IP: https://xkcd.com/195/ ipv6 same thing but bigger nft-pool.
The problem as you noticed is that internet nodes follow a contract on which packets to relay, traffic rules are strictly hierarchical.
Solving problems with supernodes will increase resource requirements indefinitely.
Prior works that provide overlay routing and transport are: TOR/onion and Batman-router.
DHTs are very efficient for service discovery, but tricky to establish a link.
My suggestion... hmm. If you want to hear it, ask.
If this system was built into the operating systems and supported by ISPs, then you could do P2P data transfer securely and all the P2P solutions (that don't even work) won't be needed
You could even generate an ephemeral identifier for each video call, file transfer etc to preserve your privacy. Or connect to your home lightning node from your phone without TOR