[REQUEST] - Standardize URL sscheme for Iroh

[RangerMauve]

Is your feature request related to a problem? Please describe.
I've been wanting to integrate Iroh into Agregore Browser but haven't had a chance to sit down and define the URL scheme for dealing with blobs and collections.

Describe the solution you'd like
I think it'd be useful if we agreed on a spec for the URLs to make website loading and creation interoperable between us.
One request I have is to try to stick as close as possible to "standard" URLS so that web engines could automatically split "origins" by the hostnames and support relative and absolute URLs.

Describe alternatives you've considered

I think pasting iroh-net tickets pretty much as is could also work but then multi-file web pages will be a bit harder to implement.

Additional context
I like your approach and I think Iroh is a great foundation for p2p file exchange

[emmyoh]

Hi! Thanks so much for reaching out! Agregore and Beaker were two projects that I found notably inspirational for wanting to include new protocols in browsers; I'm honestly a bit star-struck :)

---

My current approach is to use document IDs or document tickets (autodetecting which one it is) with a hive:// scheme prefix; I intend on adding more to the protocol beyond P2P file sharing, and I intended on eventually naming it something like Hive, hence the scheme name.

After the ID or ticket is a path to a file. For example, a link might resemble hive://somereplicaid/path/to/file.html. What I call a 'replica' is using Iroh documents to create a file system of sorts, where the 'files' are document entries.

If given a document ID, I find a peer using a DHT and ask them for a ticket. This is not implemented in Iroh itself.
If given a ticket directly, I just use that to fetch the document.

Blob tickets don't make sense to me in a browser context; if you want to retrieve a file, you can use the document ticket but filter the entries you're willing to download. Since blobs are immutable and tend to point to one entry, you'd need to get new blob tickets for any file in the same replica (or even if you want to retrieve the same file when you know it's changed).

For links to immutable content, Oku also includes ipfs://.

---

Hopefully what I wrote made sense? Sorry for my tendency to have very jumpy thoughts (ADHD). Would like to talk more about this :)

[RangerMauve]

That all makes sense! Is your protocol handling available as a standalone library somewhere? I could probably import it into Electron via Neon if so :o It'd be neat to have some interop.

Are you going to be updating to the latest version of iroh-docs? I heard there were breaking changes so I'd been holding off a bit.

I agree about the blob tickets, I'm doing a similar ish approach in veilid-iroh-blobs (WIP) except with a collection for the FS abstraction and using the Veilid DHT to advertise the latest collection hash to peers.

[emmyoh]

Is your protocol handling available as a standalone library somewhere? I could probably import it into Electron via Neon if so :o It'd be neat to have some interop.

Kind of? The browser parses the URLs in this file, and calls either fetch_file_with_ticket or fetch_file in oku-fs.

Are you going to be updating to the latest version of iroh-docs? I heard there were breaking changes so I'd been holding off a bit.

Yes, probably. I've been getting the impression the API is going to change a lot and that the closest thing to the current version of Iroh documents will be the Willow Protocol data model; I haven't actually asked about what Iroh documents will be like in the future, but it seems likely that (a) Iroh documents will continue to serve broadly the same use case and that (b) Willow's Rust implementation will not be as feature-complete or mature as Iroh currently is, though I'm saying all this strictly because of vibes.

I agree about the blob tickets, I'm doing a similar ish approach in veilid-iroh-blobs (WIP) except with a collection for the FS abstraction and using the Veilid DHT to advertise the latest collection hash to peers.

Super cool! I'd heard of Veilid but haven't looked super closely into it. I've personally found the BitTorrent Mainline DHT easier to work with thanks to a nice Rust implementation that supports mutable items. Does the Veilid DHT have some advantages that would make it more suited for what we're both broadly aiming to achieve?

[RangerMauve]

Regarding veilid I mostly like it for it's IP privacy. The DHT also has some interesting properties for coordinating multiple authors / subkeys which is handy for storing small bits of state and for discovering route IDs of members.