Egregoros

I'm certainly well aware of this...

However, there are certain necessary complexities and trade-offs of every alternative networking solution, for example you need some kind of coins to register a domain on Namecoin, ENS, PKT or Unstoppable.

Furthermore, Tor, I2P, cjdns, and Yggdrasil require installing unique software on your machine, there is configuration and sometimes security considerations, and everybody has their preference.

SLUFI does not attempt to replace any of them, but rather to make ActivityPub able to bridge over ALL of them...

@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

The "F" in SLUFI stands for "Federated", and federated means there are users who exist on servers, like Matrix and SMTP.

What you're talking about is P2P, not federated, like Bitcoin and Nostr.

I claim that cross-network *federation* is worth working on, and that's what SLUFI is about.

If you think that the fedi needs to move to a P2P model like Nostr, I don't think you're gonna get traction, but that's fine, we can agree to disagree. You're arguing with me when you should be lobbying the people who need to be convinced that P2P is better than federated...

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...

> that'll periodically fail

Might have mis-spoke here, what you want to put is the highest first_recv_time in the previous response. Failures are okay, just keep re-trying. ${exponential_backoff_best_practice_template}

> SOCKS5 might be more useful

(little known) HTTPS CONNECT switches to raw TCP so it's equivalent to SOCKS5 with the exception that it doesn't do UDP. That's actually required because SLUFI onion-tunnels another TLS through the proxy.

Huge advantage of HTTPS CONNECT over SOCKS5: You can identify with a client cert so you don't need to fuss around with per-proxy user/pass.

@i @p @lain @silverpill @jaff @cjd @mint @sun >fedi is simply not interesting enough for spam and abuse
it doesn't matter if it's interesting enough with more time that goes on more LLMs will come online, users will have chips in their phones capable of running them. eventually fedi won't even be able to work as intended because one bad actor decided to send an agent swarm to attack every instance's security, co-mingle with fedizens to prevent discourse, and autonomously OSINT users to dox them

I think that fundamentally we're solving different problems - which is cool because we can support each other.

You're trying to disconnect a node from an instance - which is a noble cause because even account portability falls apart if you get banned or the server dies...

I'm trying to fediverse exactly the way it is, no changes, and make it able to federate across boundaries - so I can setup pkteerium.pkt, you can setup mitra.bit, and providing WE configure proxies, anyone can just register to our nodes and act like nothing has ever happened - and anyone with the SLUFI code (who hasn't turned it off) will just see our messages...

@silverpill @i @p @lain @jaff @cjd @mint @sun @rees If you interpret the highlighted text in the attached pic to the maximum possible extent, which it would be in case of a dispute, making multiple requests from a server behind that domain breaks that clause. And since even updating an OS creates multiple requests a second, that also falls into that. And guess what every fedi server does. ("Service" includes domain hosting.)

I think it's there to just allow quick removal of domains they don't like, which has happened in the past (notice the ", or that" after multiple requests). They just drop domains without a word and tell you to pound sand when you notice.

https://njal.la/tos/
image.png