RINA is a Non-IP network architecture …
I wonder if Holochain can work with such an architecture ?
More about RINA : https://www.topincs.com/EntangledBootstrap/2111
1 Like
Never heard of it before you mentioned it, but it’s really interesting!
Sounds like this is a good match for Holochain 
(just an enthusiastic speaking, nothing more)
However, when searching around, I didn’t get really how much the real world usage would be nowadays (I would think 0, besides academic testing?)
I think this is more like a theoretical/future-proof question, right? Or do you have a working RINA network?
It seems that Ouroboros is a suitable alternative to RINA.
I was going to use the word ‘successor’, but they both seem active (ouroboros a bit more if comparing latest git commits and even more when comparing publications/documentation dates).
The only comparison up until now:
Ouroboros follows the recursive principles of RINA, but deviates quite a bit from its internal design. There are resources on the Internet explaining RINA, but here we will focus on its high level design and what is relevant for Ouroboros.
It however seems a bit easier (personal assessment, did not yet try) to install and try.
1 Like
RINA has been in development for a LONG time. There’s a lot that I like about their approach, and when we were designing and building our (second or third?) prototype of Ceptr, I definitely had in mind that receptors in Ceptr would communicate using a RINA-like RPC approach.
Holochain is not trying to reach quite as far as Ceptr and is intended to successfully demonstrate only a couple of Ceptr’s important principles piggybacking on largely existing standards, rather than such a massive rewrite as Ceptr involves.
That said, we used lib2p from IPFS / Protocol Labs in the prototype version of Holochain, but found that it (and pretty much all existing implementations of DHTs) really couldn’t take us where we wanted to go with a self-healing / self-balancing / sharded DHT. It also failed to solve a lot of the problems we hoped it would for reaching peers behind NATs & firewalls. In fairness, I believe there have been a lot of improvements since we used it a few years ago, but since network efficiency tuned for our purpose is so critical to the functioning of Holochain, we opted not to keep trying to bend libp2p to our needs.
It seemed like QUIC was a reasonable solid emerging standard (looking like it was going to be a part of the HTTP3 standard) and that quinn might provide a rust implementation that would meet many/most of our needs, so we went that route.
Truthfully, it has fallen a bit short for us as well, in that we really want any Holochain node (reachable by a public address) to be able to provide proxy tunnels for nodes that are not reachable on public addresses. And quinn’s implementation is a bit too monolithic for us to break it down for reusing components for tunneling QUIC in QUIC for example. So… not sure if we’re going to have to rebuild parts of this ourselves, or find other more composable tools for later stages of work.
In any case, something like RINA could theoretically work for Holochain, but we were trying to stick with more familiar standards at this stage.
I’m going to write a bit more about networking details on this thread.
-art
5 Likes