Augment irohffi.Preset with a community default? #22

New Issue

2026-10-20T08:32:27Z

cblgh commented

2026-10-20 08:32:27 +00:00

Currently our examples are all heavily leaning on the defaults beneficially provided by N0 with irohffi.PresetN0. Great for expediency, but in the long-term they are bound to make changes which will make these examples (and any other code copying the examples) stop working.

The company's stated policy is that public relay infra is provided without guarantees:

Support policy
No SLA or uptime guarantee
Only the latest stable release of iroh is officially supported (older versions may work, but this is not guaranteed and can change at any time)
No version locking; n0.computer reserves the right to remove support for older iroh versions at any time
Traffic is rate-limited to prevent abuse

https://docs.iroh.computer/iroh-services/relays/public

Based on my experience with issues Cabal ran into relying on hyperswarm defaults, the lack of version locking is probably the worst in terms of confusing disruptions coming out of nowhere. As for current issues, I think I've already run into being rate-limited a few times from my rapid-fire iterative workflow X)

Since we (or rather you 🙇 🙏) are doing this ffi layer and making changes/minor tweaks - we could provide a utility method that sets up a stable community option, irohffi.PresetCommunity or, perhaps a tiered offering - irohffi.PresetCommunityFree and irohffi.PresetCommons; the latter being a commons-only option that is restricted to people and participating projects paying dues. With community infra in place we can at least decide when to make changes and deprecations and how to communicate it.

Questions that follow from that are figuring out how to make it work (especially the DNS layer?). Things that come to mind: it would be good to set up a few different and independent relays and make sure traffic still works despite running programs using different relays, and to monitor the use - since once the infra is discovered it could become an avenue for people to use and abuse "another free infra".

I reckon the abuse of this infra is sufficiently far away that we can actually put it in place, trial using it for a while and come up with a plan before problems actually enter the picture. Abuse is (afaik) also limited to maxing out traffic, since at least N0's relay infra is all about maintaining the E2EE of Iroh. Not sure about what can be stored in the DNS layer tho.

Currently our examples are all heavily leaning on the defaults beneficially provided by N0 with [`irohffi.PresetN0`](https://godocs.io/git.coopcloud.tech/decentral1se/iroh-go#PresetN0). Great for expediency, but in the long-term they are bound to make changes which will make these examples (and any other code copying the examples) stop working. The company's stated policy is that public relay infra is provided without guarantees: > Support policy No SLA or uptime guarantee Only the latest stable release of iroh is officially supported (older versions may work, but this is not guaranteed and can change at any time) No [version locking](https://docs.iroh.computer/iroh-services/relays/managed#version-locking); n0.computer reserves the right to remove support for older iroh versions at any time Traffic is rate-limited to prevent abuse > > https://docs.iroh.computer/iroh-services/relays/public Based on my experience with issues Cabal ran into relying on hyperswarm defaults, the lack of version locking is probably the worst in terms of confusing disruptions coming out of nowhere. As for current issues, I think I've already run into being rate-limited a few times from my rapid-fire iterative workflow X) Since we (or rather you 🙇 🙏) are doing this ffi layer and making changes/minor tweaks - we could provide a utility method that sets up a stable community option, `irohffi.PresetCommunity` or, perhaps a tiered offering - `irohffi.PresetCommunityFree` and `irohffi.PresetCommons`; the latter being a commons-only option that is restricted to people and participating projects paying dues. With community infra in place we can at least decide when to make changes and deprecations and how to communicate it. Questions that follow from that are figuring out how to make it work (especially the [DNS layer?](https://docs.iroh.computer/connecting/dns-address-lookup#dns)). Things that come to mind: it would be good to set up a few different and independent relays and make sure traffic still works despite running programs using different relays, and to monitor the use - since once the infra is discovered it could become an avenue for people to use and abuse "another free infra". I reckon the abuse of this infra is sufficiently far away that we can actually put it in place, trial using it for a while and come up with a plan before problems actually enter the picture. Abuse is (afaik) also limited to maxing out traffic, since at least N0's relay infra is all about maintaining the E2EE of Iroh. Not sure about what can be stored in the DNS layer tho.

🚀 1

cblgh commented

2026-10-20 08:32:59 +00:00

(And yep this is 100% circling back to thoughts I've had previously! But is finally starting to feel very relevant to execute on :>)

❤️ 1

decentral1se commented

2026-10-20 09:23:23 +00:00

Hmmmmm, good thoughts! I'm glad youre thinking about this.

I was thinking that this indeed might become more of a collective topic of discussion when p2panda hits 1.0 and p2panda-go might be getting used more (therefore relying on iroh relays). Also WTP and willow-go are coming down the tubes (apparently not vibecoded) and will most likely make use of iroh-relays too! And ofc, iroh-go is a thing.

This is all shaping up for some sort of phoenix golang p4p-ism (or maybe we never even started so we didn't have anything to burn down so probably it's just the rise 😆). And sure, I'd like to have something community owned and run up and running before shit hits the fan 🙃

I would be happy to do some sort p4p alliance which (hand wavy guessing) maintains contact with key community (and corp but then at arms length) lib maintainers, offers the relay or other intermediary infrastructure as a commons and is a nice hangout for people who want to build together.

I am not sure if we're enough people to make this happen right now and I'm not sure if starting a proposal will gather those people or we're way too early adopter here and we should wait for a few concrete projects to turn up first 👀

I could imagine bootstrapping a single html page with a nice name, practical goal (p4p commons) and a digital place to gather might be enough for now 😛 We could migrate the repos to a shared org also, I almost never get a good vibe from a community project attached to a single devs account 😆

(I trust once we decide to commit to the relay hosting, we will make it work easy haha)

Hmmmmm, good thoughts! I'm glad youre thinking about this. I was thinking that this indeed might become more of a collective topic of discussion when p2panda hits 1.0 and `p2panda-go` might be getting used more (therefore relying on iroh relays). Also [WTP](https://willowprotocol.org/specs/wtp/index.html) and [willow-go](https://github.com/Deln0r/willow-go) are coming down the tubes (apparently [not vibecoded](https://slopscan.ava.pet/repo/https%3A%2F%2Fgithub%2Ecom%2FDeln0r%2Fwillow%2Dgo/main)) and will most likely make use of iroh-relays too! And ofc, `iroh-go` is a thing. This is all shaping up for some sort of phoenix golang p4p-ism (or maybe we never even started so we didn't have anything to burn down so probably it's just the rise 😆). And sure, I'd like to have something community owned and run up and running before shit hits the fan 🙃 I would be happy to do some sort p4p alliance which (*hand wavy guessing*) maintains contact with key community (and corp but then at arms length) lib maintainers, offers the relay or other intermediary infrastructure as a commons and is a nice hangout for people who want to build together. I am not sure if we're enough people to make this happen right now and I'm not sure if starting a proposal will gather those people or we're way too early adopter here and we should wait for a few concrete projects to turn up first 👀 I could imagine bootstrapping a single html page with a nice name, practical goal (p4p commons) and a digital place to gather might be enough for now 😛 We could migrate the repos to a shared org also, I almost never get a good vibe from a community project attached to a single devs account 😆 (I trust once we decide to commit to the relay hosting, we will make it work easy haha)

❤️ 1

cblgh commented

2026-10-20 10:27:50 +00:00

Yep I think there is potential for projects to want to use it + contribute to keep it going!

As a methodology for actually making it real, I am way more keen on pursuing a just-doing-it path and letting people join it once it exists as a thing, than I am trying to convince people and projects to get onboard and gathering blessings prior to even starting on it. The latter easily peters out and becomes very bikesheddy. As an example, I've already at a p2p-basel event voiced this exact idea and fusion but there was a cool reception to it at the time. I reckon just doing it is so much more gratifying and interesting (lots of things to learn when getting going).

I am not sure if we're enough people to make this happen right now and I'm not sure if starting a proposal will gather those people or we're way too early adopter here and we should wait for a few concrete projects to turn up first 👀

Re-reading this part, I think we're kind of aligned on the insight that going down an approach of gathering blessings isn't the most practical?

As for how to get something rolling on this, being a few merry folx, I think it amounts to doing small experiments and collecting them somewhere. So I see it starting as a research exercise to figure out "wtf is the relay doing? how does this dns look up piece work?" and spin things up that way and use our own stuff to find out the answers.

Anyway, speaking for my own projects, I'm going to want to spin up relays (and sooner rather than later) that I can use, having been burned in the past with relying on public no-guarantee infra that disappears over night. So it's pretty natural that I'll be early with doing these experiments. In terms of having available hosting hardware, I think we've certainly got machines we could use - both personally but also in our friend networks. One avenue for doing this kind of exploration on my end, and in a collective setting, would be as a focused session during one of the lowkey critical coding club gatherings I'm regularly attending.

Continuing to think out loud here and following from the above: maybe the way to do it now in the beginning, then, instead of adding it to iroh-go as a 'permanent addition', is to instead create a smol package like the below (very sketched out):

(Jasmin tea shop inspo and Iroh relevance)

// retrieved from gomod.cblgh.org/jasmine-teehaus à la cerca but hosted as source code wherever e.g. codeberg.org for easy PRs
package main 

type Preset struct { 
  Relays []string
  DNS []string
  ... other fields that would make sense
} 
// NOTE: might instead need to be a type like iroh_ffi.Preset
// NOTE: probably wiser to explicitly include versioning information based on the minimum iroh version the given infra supports, 
// that way newer relays can be added as new exports while keeping older infra around in a predictable way
func PresetPublic() Preset {
  return Preset{Relays: []string{....}, DNS []string{...}}
}

Importing + using the preset would be straightforward:

package main 
import (
    jt "gomod.cblgh.org/jasmine-teehaus"
    iroh "git.coopcloud.tech/decentral1se/iroh-go"
)
  
func main() {
    // use jt.PresetPublic()
    preset := jt.PresetPublic()
    opts := iroh.EndpointOptions{
        Preset: &preset,
        Alpns:  &[][]byte{"my-alpn"},
    } 
}
// ...

This pattern follows from what we've done with Cabal@hypercore: bootstrap_nodes.js - as you can see, we have our own nodes but also still include Holepunch's.

I could imagine bootstrapping a single html page with a nice name, practical goal (p4p commons) and a digital place to gather might be enough for now 😛 We could migrate the repos to a shared org also, I almost never get a good vibe from a community project attached to a single devs account 😆

Yeah I think this could be really nice one once there's some stuff to use. Although re being under someone's dev account - personally I really don't stress it so much in the early days looks at the nuclear fallout site of various abandoned {SSB, IPFS, Dat} github orgs. Somehow instead of the burden being shared the burden just becomes dropped entirely instead ^^'

Yep I think there is potential for projects to want to use it + contribute to keep it going! As a methodology for actually making it real, I am way more keen on pursuing a just-doing-it path and letting people join it once it exists as a thing, than I am trying to convince people and projects to get onboard and gathering blessings prior to even starting on it. The latter easily peters out and becomes very [bikesheddy](https://en.wikipedia.org/wiki/Law_of_triviality). As an example, I've already at a p2p-basel event voiced this exact idea and fusion but there was a cool reception to it at the time. I reckon just doing it is so much more gratifying and interesting (lots of things to learn when getting going). > I am not sure if we're enough people to make this happen right now and I'm not sure if starting a proposal will gather those people or we're way too early adopter here and we should wait for a few concrete projects to turn up first 👀 Re-reading this part, I think we're kind of aligned on the insight that going down an approach of gathering blessings isn't the most practical? As for how to get something rolling on this, being a few merry folx, I think it amounts to doing small experiments and collecting them somewhere. So I see it starting as a research exercise to figure out "wtf *is* the relay doing? how does this dns look up piece work?" and spin things up that way and use our own stuff to find out the answers. Anyway, speaking for my own projects, I'm going to want to spin up relays (and sooner rather than later) that I can use, having been burned in the past with relying on public no-guarantee infra that disappears over night. So it's pretty natural that I'll be early with doing these experiments. In terms of having available hosting hardware, I think we've certainly got machines we could use - both personally but also in our friend networks. One avenue for doing this kind of exploration on my end, and in a collective setting, would be as a focused session during one of the [lowkey critical coding club](https://lowkey.ursuppe.dk/) gatherings I'm regularly attending. --- Continuing to think out loud here and following from the above: maybe the way to do it now in the beginning, then, instead of adding it to `iroh-go` as a 'permanent addition', is to instead create a smol package like the below (very sketched out): ([Jasmin tea shop inspo and Iroh relevance](https://avatar.fandom.com/wiki/Jasmine_Dragon)) ```golang // retrieved from gomod.cblgh.org/jasmine-teehaus à la cerca but hosted as source code wherever e.g. codeberg.org for easy PRs package main type Preset struct { Relays []string DNS []string ... other fields that would make sense } // NOTE: might instead need to be a type like iroh_ffi.Preset // NOTE: probably wiser to explicitly include versioning information based on the minimum iroh version the given infra supports, // that way newer relays can be added as new exports while keeping older infra around in a predictable way func PresetPublic() Preset { return Preset{Relays: []string{....}, DNS []string{...}} } ``` Importing + using the preset would be straightforward: ```golang package main import ( jt "gomod.cblgh.org/jasmine-teehaus" iroh "git.coopcloud.tech/decentral1se/iroh-go" ) func main() { // use jt.PresetPublic() preset := jt.PresetPublic() opts := iroh.EndpointOptions{ Preset: &preset, Alpns: &[][]byte{"my-alpn"}, } } // ... ``` This pattern follows from what we've done with Cabal@hypercore: [bootstrap_nodes.js](https://github.com/cabal-club/cabal-core/blob/master/bootstrap_nodes.js) - as you can see, we have our own nodes but also still include Holepunch's. --- > I could imagine bootstrapping a single html page with a nice name, practical goal (p4p commons) and a digital place to gather might be enough for now 😛 We could migrate the repos to a shared org also, I almost never get a good vibe from a community project attached to a single devs account 😆 Yeah I think this could be really nice one once there's some stuff to use. Although re being under someone's dev account - personally I really don't stress it so much in the early days *looks at the nuclear fallout site of various abandoned {SSB, IPFS, Dat} github orgs*. Somehow instead of the burden being shared the burden just becomes dropped entirely instead ^^'

🎉 1

decentral1se commented

2026-10-20 12:56:08 +00:00

Wonderful, I'm onboard, good plan! I like the separate package idea (and name 🌟). My upcoming sundays are sadly quite busy but it would cool to sync check-in one of the coding club days... if you make a start on the separate package, we can focus there? I'll put it on my list to start reading up and improving my relay-fu and we can start to document our ideas on the jasmie-teehaus repo? I'll be happy to run a relay on the varia server which is pretty stable.

❤️ 1

cblgh commented

2026-10-20 13:47:23 +00:00

Woooo, glad you're onboard, excited about this!!

The lowkey meets are super nice, last time I baked and brought cinnamon buns :> If you ever have time first sunday of the month you'd be most welcome to dial in and some of us can gather in a cosy corner to chat and look at things in a shared voice + terminal session of some kind!

I'll get a start on the package!

barebones repo here https://codeberg.org/cblgh/jasmine-teehaus and added you as a collaborator
gomod.cblgh.org/jasmine-teehaus redirect operational (had to figure out once again how i managed to do my previous redirects X)

and running code!

cat main.go                               
                                             
package main

import (
        jt "gomod.cblgh.org/jasmine-teehaus/welcome"
        "fmt"
)

func main() {
        fmt.Println(jt.Welcome())
}

go run .                                                                                                             
Welcome to the Jasmine Teehaus!

Woooo, glad you're onboard, excited about this!! The lowkey meets are super nice, last time I baked and brought cinnamon buns :> If you ever have time first sunday of the month you'd be most welcome to dial in and some of us can gather in a cosy corner to chat and look at things in a shared voice + terminal session of some kind! I'll get a start on the package! * barebones repo here https://codeberg.org/cblgh/jasmine-teehaus and added you as a collaborator * `gomod.cblgh.org/jasmine-teehaus` redirect operational (had to figure out once again how i managed to do my previous redirects X) and running code! ``` cat main.go package main import ( jt "gomod.cblgh.org/jasmine-teehaus/welcome" "fmt" ) func main() { fmt.Println(jt.Welcome()) } go run . Welcome to the Jasmine Teehaus!

🚀 1

decentral1se added the enhancement label 2026-10-20 14:18:34 +00:00

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: decentral1se/iroh-go#22