Skip to main content


I don't think it was a good idea for instance admins to agree to talk to Meta under a nondisclosure agreement, but that DOESN'T make it an excuse for people to go and harass those admins. If anything they're the victims of Meta IMO, and a lot of them may still be in favor of blocking Meta regardless of whether they agreed to the meeting or not. I think we have to stick together in situations like this and act accordingly, keep in mind that "divide and conquer" is a proven strategy.

reshared this

in reply to Rokosun

Its also important to acknowledge that Fediverse has the same kind of design flaws that made it possible for Google to take over the email ecosystem with their Gmail service, @aral has written a blog post that explains this problem very well - https://ar.al/2022/11/09/is-the-fediverse-about-to-get-fryed-or-why-every-toot-is-also-a-potential-denial-of-service-attack/

So the way to move forward would be to create a system which doesn't have these flaws, and the only way to do that is to somehow get rid of the power difference between the one who can run servers and the one who can't.

reshared this

in reply to Rokosun

@aral And if you follow this to its logical conclusion, maybe get rid of servers altogether.

I mean, not necessarily *literally*. But if you can participate without having to set up *or* join a server, that'd be grand, no?
in reply to Jens Finkhäuser 🌻

@jens Eventually. It’s not an unsolvable problem if the network has enough nodes but it’s a huge one at the start concerning findability and availability. Think of always-on servers (owned and controlled by everyday people) as training wheels for the kind of world you describe. Given enough nodes and the proliferation of free and open devices (phones, etc.), anything could be an always on server in the future.
in reply to Aral Balkan

@jens (Proprietary/centralised Big Tech will fight tooth and nail to make sure that doesn’t happen, of course.)
in reply to Aral Balkan

@aral Well, we kind of had this before.

https://www.theregister.com/2007/08/20/skype_outage_post-mortem/

What happened is that Skype used a so-called hybrid p2p network, where they bootstrapped everything off two supernodes, servers they were running themselves. But because they were no longer contacted, they got shut down. Patch Tuesday meant thousands of nodes trying to re-join the network and not finding supernodes.

I know this, because at the time I was working at Joost, which used the same tech, in the p2p team.
in reply to Jens Finkhäuser 🌻

@aral So they called us and said "we aren't really set up to run supernodes any longer, could you please reconfigure yours to boostrap Skype", and we did.

The TL;DR of the story is, a fully server-less system can work very well, for years even, until a bunch of nodes disappear at the same time.

But the good news is that the only "servers" it needs to keep running under those circumstances are quite simple, and don't need to know much about anything. Add one, remove one, it...
in reply to Jens Finkhäuser 🌻

@aral ... doesn't make much difference.

So having *that* kind of server simple to run, simple enough for a bunch of folk to do in their spare time, is a big deal, because then you're pretty much where you need to be: resilience without the single point of failure/control.
in reply to Jens Finkhäuser 🌻

@jens @aral
Another way to express that is that it's all in queues, the queues can be replicated and it's all pub/sub.

It's convenient to sink it to particular nodes, but it might as well be a CDN.
in reply to Simon Lucy

@simon_lucy @aral Kind of, yes, but a CDN implies ownership of the distribution method. You don't need that.
in reply to Jens Finkhäuser 🌻

@jens @aral
True, though we had alternative vendors at the Beeb which could be given different proportions of content ( probably not any more), and in the end it's just cache and peering relationships. If it's not big enough to need that kind of acceleration then just cache.
in reply to Simon Lucy

@simon_lucy @aral Yeah, but it's all Beeb owned or rented content. When everyone owns their own toots, there's a power imbalance here - unless every individual is in control of who peers with them.
in reply to Jens Finkhäuser 🌻

i’ve always wondered if it’s possible to bootstrap new services off of bittorrent’s dht. it’s had the ability to store (and update) data for almost a decade: https://www.bittorrent.org/beps/bep_0044.html

however, i don’t know how widespread support for this is in clients.
in reply to faried nawaz

@fn Yes, it is, but a DHT is not necessarily the most effective structure.
in reply to Jens Finkhäuser 🌻

@jens that is something i was just thinking about, but i have not enough knowledge on how activity pub works for playing with it. It would be super interesting to move from a decentralized to a more distributed system
in reply to Jens Finkhäuser 🌻

@jens @aral I've been thinking along similar lines. I have tremendous respect for Aral and what he's building but maybe for some use cases a domain-less solution would be an option? Maybe ActivityPub json (or other protocol) could be transmitted via email? Or a loose store-and-forward network like Usenet which is agnostic as to the underlying transport layer? To be sure this loses some functionality, but I can imagine upsides in some cases too.
in reply to Popstar Tourist

@octonion888 Thanks. And the two don’t have to be mutually exclusive either. It’s going to be fun looking at how different pieces do/don’t fit together once I’m finally done building infrastructure 😀

@jens @futureisfoss
in reply to Aral Balkan

@aral @octonion888 @jens

I'm also a big fan of these domain-less peer-to-peer services and have been keeping an eye on the developments there. One such decentralized p2p project I know is the @briar messenger and they've recently announced the release of their new Briar Mailbox app, which is an app you can just keep running on an old android device or something and it basically turns it into a server for sending & receiving your Briar messages! - https://briarproject.org/news/2023-briar-mailbox-released/
in reply to Rokosun

@octonion888 @jens @briar

Like @aral said, they're all different methods/solutions for tackling the same problem, and they don't have to be mutually exclusive with one another. Its good to have different options at our disposal 😉
in reply to Rokosun

@aral @octonion888 Yep.

What I'm building with @interpeer is similar enough from 10,000ft, but is really less about "a messenger" or "a social media app", and more about re-imagining a generic (stack of) protocols where HTTP and TCP would be nowadays, with a tentative view to pushing into IP extensions (rather than replacing IP, though I'm open to that in principle).

Because of that genericity, a whole lot of individually relatively small things are different from...
in reply to Jens Finkhäuser 🌻

@aral @octonion888 ... the p2p stacks I've seen. And I do keep looking at what else is out there, so I'm always happy for suggestions!

But of course I know about scuttlebutt and briar.
in reply to smallcircles (Humanity Now 🕊)

Some of the other less well-known p2p mesh networks I've heard of:

https://reticulum.network/ and the GUI app for it https://github.com/markqvist/sideband. These projects are still in their early stages and the last time I tried it out there were many bugs, tho its still an interesting project to keep an eye on.

https://yggdrasil-network.github.io/ - this one seemed more technical to me but from what I understand it helps liberate your IP address or something like that 🤷
This entry was edited (10 months ago)
in reply to pettter

@pettter It's neither, really. It's taking an information centric networking approach with enough tweaks to make it "real-time" aka streaming capable. That means giving the application more control over reliability characteristics, shaving off round trips, etc.

But it also means more aggressively taking out single points of failure. I was recently editing https://specs.interpeer.io/draft-jfinkhaeuser-caps-for-distributed-auth/draft-jfinkhaeuser-caps-for-distributed-auth-02/ which is about authorization without having to ask some auth server.

@futureisfoss @aral @octonion888 @interpeer
in reply to Jens Finkhäuser 🌻

@pettter @aral @octonion888 It's early-ish, though. Not all parts are there. But we're building it in parts also because then some parts can be (relatively) finished, and maybe re-used.
in reply to Rokosun

Working on it… 😀

https://ar.al/2020/08/07/what-is-the-small-web/

#SmallWeb

reshared this

in reply to Aral Balkan

@aral I really like your vision of a small-web and I agree that it should be the future of networking. And its great that you're working on creating the basic developer tools which we'll need to build such a decentralized web, your work is very much appreciated 🙏

Also not gonna lie, Kitten is the cutest software project I've ever heard of :blobcatgiggle:

Steve reshared this.

in reply to Rokosun

well there is Nostr, which is true p2p but it’s complicated and much less usable than Mastodon. But really what you are talking about is the natural repercussion of any market system: larger gobbling up the estate. It’s a natural effect, which can only be limited through keeping protocols and opportunities open for all. Well, regulation too, but I’d rather avoid that as a very heavy handed solution.
in reply to Kristoffer Lawson

From what I've read about Nostr so far it still relies on servers so maybe not truly p2p like you see in messengers like Briar. Nostr sounds a lot like RSS feeds but when used for social networking instead, I really like that concept. My only issue with Nostr is that community's obsession with cryptocurrencies, I'm personally not a big fan of adding crypto transactions to a social media app, and because most Nostr clients have that it kinda puts me off. Tho I still like the Nostr concept.
This entry was edited (10 months ago)
in reply to Rokosun

@Rokosun Which is exactly what Nomadic Identity aims to solve. Your identity and your content is not bound to the server you happen to be logged in to.

Not only can you take your identity and content to a new server, but you can keep one or more live clones so that if your main server goes down (permanently or temporarily) you can just log in to one of the clones and carry on as usual. Useful as a backup, but also in case your main instance suddenly shuts down or kicks you out.
in reply to Harald Eilertsen

@harald I've heard of nomadic identities in Hubzilla before and I'd say its surely more open & flexible than Mastodon, there is still some power difference between the one who owns these servers and regular users but it sure adds some resilience when you can clone your account on multiple servers.
in reply to Rokosun

@aral

I'm a tech consultant who has been building email systems for over 25 years and using email for over 35 years.

Google didn't "take over the email ecosystem", and any suggestion that they did so displays a complete lack of understanding of the email ecosystem.

Gmail provided a better "free" email system than Hotmail, etc. There are many, many ways to use email that don't involve Google, many free or so low cost as to be insignificant.
in reply to gcvsa ⭐️🔰🇺🇸 🇵🇭

in reply to Rokosun

@roko @aral

If you are going to make quantitative statements about email usage, you are required to show evidence affirming your claims. "Vast majority of email users"? Show your data.
in reply to gcvsa ⭐️🔰🇺🇸 🇵🇭

in reply to Rokosun

#TradeRuinsEverything to use a hashtag you came up with ;)

I have said since the moment I discovered this fediverse network that nothing escapes the forces of trade. Facebook (fucking Meta name man 😁 ) wants to trade with people, so if they see the fediverse growing they'll jump and try to conquer it. Happened to pretty much everything, from software to products or events.

Defederating with them does not seem a solution for me. Rather let people get used to the fediverse through them, and then maybe they can move to different instances. But what's sure in my mind is that everything that's free and good (purely free and good) is fragile in this trade society.

Rokosun reshared this.

in reply to Tio

in reply to Rokosun

And yet this is an example of the greatest flaw of Federation: in that defederation is tantamount to censorship by any other name.

Decentralization is the ideal: where the user chooses what to view or block, not a gatekeeping admin making that choice for them.

The Fediverse is feudal at its core, and I'm not sure how evenly this problem is spread between ActivityPub (the protocol) and instance admins (the people).

Protocols > People? People > Protocols? I choose the former.
in reply to Paramdeo Singh 🇬🇾

in reply to Rokosun

@paramdeo With Meta coming to fedi I'm not so sure if defederation is the right choice here, but we'll have to see how their "profit making venture" impacts regular users of fedi, at the moment we have no idea how their business model works and that is a big question. Will they collect people's data? Put ads on their timeline? Or add paywalled features like the Twitter blue check mark? Such a big company like Meta could really make an impact here with their resources, that's why we're concerned.
in reply to Rokosun

Yeah I'm against any form of defederation outside of CSAM, but note that Meta isn't forcing anyone to use their (potentially ad-driven) instance, and so that choice is left entirely up to the user if they find the service compelling.

Like with Twitter under Musk, I think some Fediverse admins that are pro-censorship are afraid that Zuckerberg won't allow censorship. Coupled with the enormity of Meta's userbase that kind of freedom makes radical instances that defederate obsolete.