Live data from Hacker News

We need a federation of forges

blog.tangled.org

241–250 of 424 posts

Re: We need a federation of forges

#241
post #209

How will this end up going any better than Mastodon has? Near inevitabilities: - All the small instances defederating from the largest due to politics/spam/annoying noobs/whatever, effectively killing the easiest path to entry into the community - Pointless debates about whether it’s OK to federate with instances that host pirated content, disagreeable politics, furry VNs, etc., which everyone has to take a side (the…

Atproto isn’t “many servers sending messages to each other”. It’s structured more like RSS: 1) there’s an app-agnostic hosting layer (and anyone can run a host, a bit like personal site with RSS) 2) then there’s apps, which aggregate over data from all hosts (a bit like Google Reader or Feedly) So there’s no such thing as “defederating”. You don’t have many copies of Tangled beefing with each other. It’s more like yo…

> Atproto isn’t “many servers sending messages to each other”. It’s structured more like RSS

Except that, crucially, RSS/Atom plays well with static nodes (e.g. personal websites generated with Jekyll/Hugo/whatever—or even written by hand[1]), and Atproto does not. (Nor does Mastodon; previously: https://news.ycombinator.com/item?id=30862612>.)

It'd be great if the complexities needed to support the "Atmosphere" were widely recognized/acknowledged to be overkill and soon enough ended up going the way of things like CORBA and WSDL while in its place a resurgence of interest in the Atomsphere emerged.

1. https://m15o.ichi.city/site/writing-atom-feed-manually.html>

Re: We need a federation of forges

#242
post #209

How will this end up going any better than Mastodon has? Near inevitabilities: - All the small instances defederating from the largest due to politics/spam/annoying noobs/whatever, effectively killing the easiest path to entry into the community - Pointless debates about whether it’s OK to federate with instances that host pirated content, disagreeable politics, furry VNs, etc., which everyone has to take a side (the…

Atproto isn’t “many servers sending messages to each other”. It’s structured more like RSS: 1) there’s an app-agnostic hosting layer (and anyone can run a host, a bit like personal site with RSS) 2) then there’s apps, which aggregate over data from all hosts (a bit like Google Reader or Feedly) So there’s no such thing as “defederating”. You don’t have many copies of Tangled beefing with each other. It’s more like yo…

The web is already structured like this. You can poll a URL for updates. You can host your own data. Anyone can build an app that aggregates from everyone's data.

Re: We need a federation of forges

#243

It took me a minute to figure out what this was even talking about. Tangles is, apparently, a gitlab-type project where PRs and bug reports and stuff are available on something called "at protocol" which is the bluesky social network "federated protocol". at protocol competes with ActivityPub, which is mastadon -- so you could, in theory, have a little federation of gitlabs peer-to-peering with each other, which is d…

except it isn't at all like ActivityPub and is implemented radically differently to avoid many of the problems with ActivityPub.

Re: We need a federation of forges

#244
post #226

Looks really cool but ATProto means I won't be using it. I'm not going to invest in another network when we already have an open one. We already have the web. The web already has OAuth. OAuth is already widely supported. IndieAuth already offers a very simple and standard approach to personal OAuth servers, if people really want to run their own identity server. "Feeds" are perfectly doable using the web. It's alread…

The web still has other protocols on top of it, like RSS. Just because the "web" exists doesn't mean that solves every problem.

Also OAuth only handles auth and permissions and doesn't do anything for provided federated views of disparate data sources.

Also this isn't about identity either, you're really misunderstanding what this is about.

Re: We need a federation of forges

#245

I'm a huge supporter of federation, but I've never understood the use-case for a "federation of forges". What data are the forges exchanging? Why should the forge for Blender have any connection to the forge for Ubuntu? Most of the value I get from Github is having a single login that I can take from project to project. Independent forges can get the same value simply by supporting social login, without needing the c…

If people want to find software, they search GitHub. If you self-host a forge, no one will ever find your software unless you’re a preestablished big name (like Blender). To avoid throwing your code into the void, you’re pretty much forced to mirror with GitHub, at least. To avoid this and make smaller forges as a block a viable competitor, there needs to be a singular network that solves discoverability and lets you…

This is an indexing problem, not a federation problem. Personally, if I want to find software, I use Google, Rubygems, or NPM. Github is a distant third option. But this project is about data interchange between forges. It doesn't solve the indexing / discoverability problem.

Having a better code search crawler that can grab data from independent git repos would be really cool. But being able to submit a PR from server 1 to server 2 is pretty unrelated to that.

Re: We need a federation of forges

#246
post #122

Earlier quoted context omitted.

How much work are you putting into simplicity? In my experience, in order for software to be permanent it needs to be like mold: only a single spore is required to grow a massive fruiting body and the spores themselves are very small and very uncomplicated. In this case, a spore is a single developer, and the simplicity is a low skill ceiling. Reproducibility does not benefit longetivity if the preconditions themselv…

I've written about this: https://anirudh.fi/future

there's something about new VC fundedbro narcissism that's so fascinating

> GitHub? Where do we even begin…

The problem with GitHub is neither its UX nor its functions. Its downfall is VC funding but you made sure to only copy that and none of the good things.

> GitLab? Way too enterprise-y, and definitely not easy to self-host.

The only reason you don't offer an enterprise version yet is because atproto sucks and there's no way to make it private. Do you honestly think VCs are paying you to play with your strings and sheep? Your users won't pay for anything because there are already free alternatives that don't force them to join yet another cult. "Why should I join tangled? uhmmm it's like a worse version of everything but it has atproto! you like atproto don't you, 14 year old well established project will millions of users?"

> Sourcehut? So opinionated it alienates about 98% of potential contributors. Pretty great if you really love email, I guess.

Do you hear youself? In what world is tangled not extremely opinionated that alienates everyone but hardcore atproto followers? "pretty great if you really love atproto i guess".

> Forgejo/Gitea? Nice, sure. You can self-host—but without a shared identity, I still need to create an account on your instance just to send a PR.

It also works and is widely used and battle tested. Has a familiar UI and CI. Oh and apparently this newfound concept called private repos.

> Radicle? Honestly, it’s amazing. Purely technically, Radicle is far ahead of anything else, Tangled included. But the world—at present—just isn’t ready for full-on P2P.

The world is ready for appview + pds + did + ... yeah okay. Only hardcore atproto fans wants this bs.

Re: We need a federation of forges

#248

I'm a huge supporter of federation, but I've never understood the use-case for a "federation of forges". What data are the forges exchanging? Why should the forge for Blender have any connection to the forge for Ubuntu? Most of the value I get from Github is having a single login that I can take from project to project. Independent forges can get the same value simply by supporting social login, without needing the c…

Git is decentralized by design. It can support federation, it just happens that GitHub solved the UI, issues, PR so that even new comer can come in and do git stuff and track issues on the screen. But centralized it. Federation would be closer to git, but not so decentralized that when one node goes offline you may not have any upstream to pull from, or not be able to find them. Git doesn't solve availability. Federa…

[deleted]

Re: We need a federation of forges

#249

I'm a huge supporter of federation, but I've never understood the use-case for a "federation of forges". What data are the forges exchanging? Why should the forge for Blender have any connection to the forge for Ubuntu? Most of the value I get from Github is having a single login that I can take from project to project. Independent forges can get the same value simply by supporting social login, without needing the c…

In this case the benefit would be: - your data lives in one place, your Personal Data Server (PDS). You can self-host this if you like - The AppView (in this case, tangled.org) aggregates the data from many PDS's into one view. - If tangled.org enshittifies, you can do all the same things from any other AppView -- tangled.org itself is not privileged in any way. Social logins on independent forges help, but personall…

In this case the PDS is only storing social data though, right? The forge would still store the repository data itself.

Re: We need a federation of forges

#250
post #226

Looks really cool but ATProto means I won't be using it. I'm not going to invest in another network when we already have an open one. We already have the web. The web already has OAuth. OAuth is already widely supported. IndieAuth already offers a very simple and standard approach to personal OAuth servers, if people really want to run their own identity server. "Feeds" are perfectly doable using the web. It's alread…

The thing about file formats is that there are so many to choose from. From a distance they may seem much the same, but ATproto has its own conventions for database records and links between them that makes it easier to replicate data without breaking references.

It's like records are born to replicate for better or worse. They get downloaded immediately and you have no control over where they go after that. Anybody can tap into one of the firehoses spewing them all over the place. But they're all linked together and if links break it's because nobody kept a copy of that record.

Other file formats don't work quite the same way. A git repo is easy to clone and pull from, but things like call graphs are language-specific.

It seems hard to say what apps this sort of replication is right for.

Post reply on HN