3 ms·

The "ideas from WebFS" that are mentioned in the README are just building a filesystem on top of 2 well defined primitives: compare-and-swap cells and content-a

The "ideas from WebFS" that are mentioned in the README are just building a filesystem on top of 2 well defined primitives: compare-and-swap cells and content-addressed storage. Those primitives are general enough to deal with the network and encryption. WebFS tried to allow specifications for cells and stores to live as files in the filesystem, so that submounts could be set up recursively. Got takes the approach of just creating a namespace for branches where each branch contains a cell and store. Got is an INET256[1] application. Got uses the go-p2p library on top of INET256 to get a reliable request-response layer, since INET256 only provides the same guarantees as DTLS. Each repo has an address on the network which is used to identify remote branches and for access control. You have to configure peering/port-forwarding once for INET256 and then Got should just work. [1] https://github.com/inet256/inet256 https://github.com/inet256/inet256

cookiengineer 5y ago
> casually drops his own routing mechanism Damn, inet256 is actually very nice as well. I'm currently reading through its architecture, so far I like that it's just a layer that can reuse existing infrastructure and that it's deriving its addresses from the public keys directly so it is very flexible in its use cases. Are there predefined ways for peer discovery? The architecture [1] document doesn't mention things like hole punching, NAT breaking (like pwnat), TURN/TURTLE routers or NAT tracing via UDP TTLs and multicast, so I'm a bit curious how peers would discover themselves in such a setup with their necessary transport layer information (IPs, ports, punched holes with internal UDP ports, UPnP config etc). In my case I decided to implement a custom DNS (over TLS/HTTPS) that's verifying the pushed updates of entries via the TLS client certificates, and those are namespaced via their own subdomain (which is also the subject part of the TLS certificate). This way the initial DNS answer that is sent from the peer to the server contains all information that's necessary for other peers to connect to them later. [1] https://github.com/inet256/inet256/blob/master/ARCHITECTURE.md https://github.com/inet256/inet256/blob/master/ARCHITECTURE....
- brendoncarroll 5y ago
  There is an interface for address discovery [1] (finding transport addresses for peers you know about) and autopeering [2] (peering with peers you didn't know about beforehand). There is an unfinished branch for LAN broadcast discovery/autopeering. Contributions are definitely welcome here. I had played around with a STUN transport, but the easiest way to connect has been to stand up a cloud VM with a static IP. INET256 addresses use the same public key serialization as TLS, but they intentionally avoid the rest of the certificate infrastructure complexity. They make great leaves in a web of trust. You can sign them, or stick them in DNS records. And if you don't want to deal with any of that, fine, just swap addresses and you can communicate securely. [1] https://github.com/inet256/inet256/blob/master/pkg/discovery/api.go https://github.com/inet256/inet256/blob/master/pkg/discovery... [2] https://github.com/inet256/inet256/blob/master/pkg/autopeering/api.go https://github.com/inet256/inet256/blob/master/pkg/autopeeri...

cookiengineer 5y ago

> casually drops his own routing mechanism Damn, inet256 is actually very nice as well. I'm currently reading through its architecture, so far I like that it's just a layer that can reuse existing infrastructure and that it's deriving its addresses from the public keys directly so it is very flexible in its use cases. Are there predefined ways for peer discovery? The architecture [1] document doesn't mention things like hole punching, NAT breaking (like pwnat), TURN/TURTLE routers or NAT tracing via UDP TTLs and multicast, so I'm a bit curious how peers would discover themselves in such a setup with their necessary transport layer information (IPs, ports, punched holes with internal UDP ports, UPnP config etc). In my case I decided to implement a custom DNS (over TLS/HTTPS) that's verifying the pushed updates of entries via the TLS client certificates, and those are namespaced via their own subdomain (which is also the subject part of the TLS certificate). This way the initial DNS answer that is sent from the peer to the server contains all information that's necessary for other peers to connect to them later. [1] https://github.com/inet256/inet256/blob/master/ARCHITECTURE.md https://github.com/inet256/inet256/blob/master/ARCHITECTURE....

brendoncarroll 5y ago
There is an interface for address discovery [1] (finding transport addresses for peers you know about) and autopeering [2] (peering with peers you didn't know about beforehand). There is an unfinished branch for LAN broadcast discovery/autopeering. Contributions are definitely welcome here. I had played around with a STUN transport, but the easiest way to connect has been to stand up a cloud VM with a static IP. INET256 addresses use the same public key serialization as TLS, but they intentionally avoid the rest of the certificate infrastructure complexity. They make great leaves in a web of trust. You can sign them, or stick them in DNS records. And if you don't want to deal with any of that, fine, just swap addresses and you can communicate securely. [1] https://github.com/inet256/inet256/blob/master/pkg/discovery/api.go https://github.com/inet256/inet256/blob/master/pkg/discovery... [2] https://github.com/inet256/inet256/blob/master/pkg/autopeering/api.go https://github.com/inet256/inet256/blob/master/pkg/autopeeri...