From a versioning control point of view WebDAV seems to be exactly the thing that you're trying to achieve, especially in regards to Delta-V?
I might be wrong, did I miss something? I guess what I'm trying to find out is what the ultimate goals or features of the WebFS are, given that WebDAV exists and is supported by git as a remote filesystem. WebDAV seems to have a specification and lots of support by other server implementations, so I'm wondering what kind of featureset was missing in there that WebFS now includes.
The overall internal cell/branch structure of got seems to be similar to how git uses blobs and trees as a list of references to blobs.
You seem to have also built a p2p library which I found pretty neat and might also be interesting to other HN readers (go-p2p) [3] that you use now as a transport layer. What I specifically liked about it is that it's based on QUIC, so it has no troubles staying under the radar of traffic classification, while still being able to punch holes. The generic abstraction by different protocols is really nice, and similar to what I've tried to do with my p2p networks. Seeing network protocols just as a way to transport (or encapsulate) things usually makes the logic behind swarm interactions more robust.
[1] https://github.com/brendoncarroll/webfs/blob/master/pkg/webf...
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.
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....
