Egregoros

SLUFI is published!

https://thegoodwork.substack.com/p/slufi

A Simple, Lightweight, Unopinionated, Federation Interconnect.

The problem: While numerous network transports exist (cjdns, Yggdrasil, I2P, Tor, etc), and numerous name services exist (Namecoin, ENS, Unstoppable Domains, PKT, etc), almost all federation takes place over ICANN+IP because we currently have no way to federate across network boundaries, and ICANN+IP is the only thing that everybody has.

I claim that there is no possible solution SIMPLER than SLUFI, except with central authority or PRECIPITOUS loss of security. Furthermore, I claim there is no possible solution that is more secure than SLUFI, except with something like a blockchain and a PRECIPITOUS loss of simplicity.

So while I do not think this protocol is complete (yet), I do think SLUFI is the only realistic starting point for reaching a solution to this problem.

Tagging some people who might be interested:
@sun
@lain
@p
@mint
@jaff
@silverpill

I probably forgot a bunch of very important people, apologies in advance...

@cjd @p @lain @jaff @mint @sun

The problem: While numerous network transports exist (cjdns, Yggdrasil, I2P, Tor, etc), and numerous name services exist (Namecoin, ENS, Unstoppable Domains, PKT, etc), almost all federation takes place over ICANN+IP because we currently have no way to federate across network boundaries, and ICANN+IP is the only thing that everybody has.

I already solved that problem: https://codeberg.org/fediverse/fep/src/branch/main/fep/ef61/fep-ef61.md

It is a transport-agnostic federation protocol that is backwards compatible with ActivityPub.

</thread>

If I understand right, in your proposal everybody needs to convince one or more gateways (who have HTTPS / ICANN domains) to host for them.

I gather the identities of the gateways are transmitted when a message from the actor is transmitted. And as long as you don't change ALL of your gateways at once, the learned information remains valid for responding.

If I'm not mistaken, you cannot just tag @somebody@someinstance.i2p and have that work, unless you've seen some message from them before which provides their gateways...

Actually on second thought, I suppose names *cannot* be @name@instance.tld because there's no way to verify someone isn't lying about owning instance.tld, so names need to be key-like, like names in Nostr (?)

@cjd @p @lain @jaff @mint @sun

>in your proposal everybody needs to convince one or more gateways (who have HTTPS / ICANN domains) to host for them.

Relays can be onion services, eepsites, etc.

I think they don't even need to talk HTTP, although this HTTP servers are the most well-understood.

>If I'm not mistaken, you cannot just tag @somebody@someinstance.i2p and have that work, unless you've seen some message from them before which provides their gateways...

You can (example: @minimitra ), but normally webfinger address belongs to the primary gateway.

>Actually on second thought, I suppose names cannot be @name@instance.tld because there's no way to verify someone isn't lying about owning instance.tld,

Gateways are advertised via actor object, which servers can't tamper with. Verification of a handle is done by checking:

- Actor.gateways contains hostname
- acct:username@hostname resolves to Actor

>so names need to be key-like, like names in Nostr (?)

The canonical identifier of @minimitra is

ap://did:key:z6MkumzpDj1cYZD2GrBbVT86xL6CfPuyqWZAEXMfSqN9j3hf/actors/019c4320-5a91-59c3-0092-16976328fd80

@cjd @p @lain @minimitra @jaff @mint @sun

>Then I gather minimitra would have a different name depending on which gateway it reached me from (?)

Currently I require handles to be constructed from the address of actor's primary gateway (the first address in the Actor.gateways array). This is for compatibility with Mastadon.

If you're willing to break ties with Mastadon, then multiple handles shouldn't be a problem, I think. One for each gateway.

>Also I suppose you kind of have to register your name at each gateway because if someone wants to tunnel a name called cjd, and through my instance, that's a collision...

Yes, there's a registration process: https://codeberg.org/fediverse/fep/src/branch/main/fep/ae97/fep-ae97.md

Okay so assuming everybody adopts everything, Mastodon included - what we end up with here is a name per-gateway...

Cynics will say "why don't you just use a boost-bot?"

My concern is more like:
Is anybody going to ACTUALLY run a node in Tor/I2P/etc if every user on that node needs to go register to get syndicated on some gateways?

Admins don't generally want to give out accounts like candy because it's a spam vector and it damages their server's reputation, so registering on a gateway is probably never going to be entirely API/seamless...

So if you need to register on gateways anyway, well, why not just make your account there... So I'm afraid that human behavior would converge on just doing what we're doing already...

---

Zooko's Triangle is a bitch, no doubt about it. And to the extent we're trying to protect the global nature of a name, it's something we've got to solve.

SLUFI's answer is to make somebody else's name system do the heavy lifting, and then solve an "easier" version of Zooko's Triangle using the WoT. It's easier because at this point because the network is talking about facts, either mysite.bit exists or it doesn't, so if two nodes disagree then one is lying...