[LukeB42]

I've found IPFS very interesting and reccommended it to peers, but it lacks the collaborative editing aspect.

Trusting the initial public offering of a resource is still an interesting issue. IPFS is content-addressable by hash, addresses map to their content in a computable way.

The idea for the distributed hash table in Uroko is that the keys are existing URLs. Imagine thousands of peers all saying they have a new page on the domain "google.com" and you can see what makes this a fun problem to solve.

[notduncansmith]

> Trusting the initial public offering of a resource is still an interesting issue.

As you mention, resources on IPFS are addressed by the hash, so I'm curious what you mean by "trust" here - do you mean that you can't trust the accuracy/validity of the content? I would assume that content on this kind of network is signed by the publishing party, so if the signature checks out against your PKI, you can trust the content.

I'm also curious as to why Git (or a spiritually similar adaptation) doesn't fit the needs of what you have in mind. Come to think of it, I don't think I see the use-case for Uroko - would you mind explaining?

[LukeB42]

Yes and thank you for your question. I mean the accuracy of the content. As users of a web that's been embedded in a distributed hash table where URLs are the keys and revisions of content are possible values, we will want some peace of mind if an organised party configured nodes to insert advertisements, for example. This means all nodes have an altruism score associated with their public key, and the system being designed to help a node perform a distributed summation of a node's altruism score, producing a positive or negative total. It means having some way of verifying if content you received was good, and some way of rating your act of rating, based on your altruism score.

Another thing is that for obvious reasons initial tests of the network ought to redact all <script> tags from documents before they're ever sent to a browser. It also means manually implementing same-origin policy due to the proxy address being the origin of every script being served to you.

Uroko intends to be a spiritually similar adaptation of git. If you look at the models.py the concept is based on revisions that belong to a path, which belongs to a domain. Think of them as commits on a branch belonging to a project.

So it is a spiritually similar adaptation of Git, but Git isn't an overlay network, which gives us an addressing scheme to identify nodes independent of their ipv4 or ipv6 addresses (Kademlia gives a routing scheme with a possible 2^160 node IDs..), message rebroadcasts, pings, helping peers bootstrap in and transmitting peers you know of in every message, tolerating node failures and ensuring no one is left out of what is an ad-hoc system built on an ad-hoc peering arrangement has been demonstrably well served by the use of this sort of overlay network.

Also Git is not an HTTPD. Uroko is, and a design goal is to support users simultaneously collaborating on the same document in soft real-time. You should be able to synchronise your cache of the web with friends directly, edit over the lan/vlan, and generally keep popular sites available to nodes in your overlay routing table.