#iroh

I finally got around to trying #iroh It nicely complements FEP-ef61, because it allows you to connect to another actor by its did:key. In theory, we can completely replace the federation of HTTP servers with a federation of iroh nodes. However, I'm not convinced that iroh is the best solution. The most obvious problem is a lack of anonymity. Newer versions of iroh support custom transports, and Tor transport is among them, though still experimental. The work on I2P transport has not started yet. Another problem is the requirement to be online all the time. A potential solution is iroh-gossip, which I haven't tried yet, but I doubt that it works good enough for nodes that come online once per week. A more traditional approach to FEP-ef61 with a combination for clearnet, tor and i2p gateways might be simpler and better. But iroh is an interesting project that's worth keeping an eye on. https://codeberg.org/silverpill/minimitra/src/commit/2dd4e4f82b476f6b0a3d2610f158691ad5f46d11/src/p2p_iroh.rs

So git-remote-iroh works, but it's basically a toy demoware. I mean, you can push and pull over iroh, which is cool, but it's not this hub-breaking new thing that changes development workflows and defeats corporate hegemony over open-source software. The server mode is still a centralized hub. I've been thinking this week about where to take it next, if I should at all. Where my head is at: All repository clones could be remote peers that you can pull from. It should be easy to do this from a background process that spawns and stays running in the background. Could be on-demand, like how podman and gpg-agent do. Because it's pull-only, it should be safe to serve this up from a clone with a working tree. Hubs allow pushes, but don't attempt to force a single history. They are a synchronization point for blobs, tracking who has what blobs. All remote refs. What this does, is remove the need for everyone being online all the time. Who decides what is the true timeline then? Up to a peer that decides to act as a publisher, and who follows it. What's nice about this, is you can have a primary and following replicas. You could even have multiple such primaries, possibly with different policies. #git #iroh #p2p #nohubsjustspokes 1/

What keeps this from degrading into total chaos, is some notion of identity. If I start a project, I'm signing my commits with an SSH key and publishing them with an iroh key. These public key identities can be bound with an attestation; I sign my iroh key, which determines my network endpoint, with a well-known SSH key that is at least pinned to the content I'm producing. What's neat about these attestations in a public-key based networking system like #iroh, is peers can attest to each other. I could sign an attestation that I know another developer -- or sign a revocation if that developer becomes compromised, or leaves the project. Attestations linked to public key infrastructure we already use like published GPG and SSH keys, bootstraps some trust into the system. This is as much a social experiment as a technical exploration. I'm using git because it's a system I kind of know, but I'm also thinking about how other collaborative apps might work at the back of my mind. 2/

Serve & clone #git repositories #p2p over #iroh! Try it out: cargo install git-remote-iroh git clone iroh://92fbc10667b6ae60b2b7c158ec3c996ebdeac0f07d6648b87243fe49498bd378 git-remote-iroh git-remote-iroh is self-hosted. #distributed #dweb #nohubsjustspokes Centralized web mirror: https://codeberg.org/cmars/git-remote-iroh

@Wrewdison@masto.hackers.town Made some progress on some access controls for my #git protocol adapter for #iroh! It currently works but anyone can push to the repo if they know the endpoint 😅. Fixing that soon and then I will self host the project. https://codeberg.org/cmars/git-remote-iroh

#iroh is pretty neat

@teohhanhui@mastodon.social I've been playing with #activitypub ideas in https://codeberg.org/cmars/medina recently (very incomplete and slightly incoherent rough sketch). I had this idea of a hub or relay where the identities are moderated but the clients own their keys and data in a portable #sqlite db which could be hosted by an instance or relayed. Exploring that balance between moderation and autonomy. I'm also testing some of these ideas with #veilid in another project that I haven't shared yet. Looks like you're using #iroh which I haven't tried yet. It's hard for me to commit to side-projects right now, but very interested to see how your project goes!

@poes@sok.egois.org @nawanp@fe.disroot.org ada kok buat host sendiri #deltachat: #chatmail. Tapi gak usah chatmail pakai SMTP dan IMAP biasa juga bisa kok. Dah pernah coba. Paling "agak boros" batere kalo IMAP nya gak support IMAP IDLE. Dan create user nya gak bisa dari aplikasi deltachat. Sebenernya masalah quota di nine.testrun.org atau host lainnya itu cuma bakal ngaruh buat offline message. Deltachat pakai email itu cuma buat relay kalo pas offline dan kalo gak salah bantu discovery. Begitu online dan kesedot, selanjutnya antar deltachat baik dengan akun lain ataupun akun sendiri kalo multiple device dia p2p pake #iroh. Tapi kalo mau agak gede quota nya, pake relaynya dari #arcanechat, dapat 2GB

@poes@sok.egois.org gak bro, itu gak ada server sentralisasi, #sendme pakai #iroh buat broker bantu discovery #p2p. Selanjutnya data diambil p2p

Sepertinya bakal stay pakai sendme buat kirim-kirim file secara gampang dari cli https://www.iroh.computer/sendme Alternatif lain ada croc. https://github.com/schollz/croc #sendme #iroh #linux #cli

It's really frustrating that the #iroh stack is not built on #tower#rustlang #rust