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 correct side) on
- Relatively little actual work/productive discussion going on, since many users are there mostly for the politics / fediverse posturing than for actual work
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 you can run your own hosting for your own data (if you want), and anyone can build an app that aggregates from everyone’s data (Tangled is one such app).
> 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.
Atom was designed for news, before social media existed, where 15+ minute polling times were (borderline) acceptable. Atproto was designed for social media, in an age of Twitter users getting their news in seconds, to the point of being able to comment on live events play-by-play. There's no coming back from that world.
With that said, I wish both Mastodon and Atproto supported opt-in pull-based, static sources.
> Atproto was designed for social media, in an age of Twitter users getting their news in seconds, to the point of being able to comment on live events play-by-play.
And this is widely recognized by now to have been a very bad thing, even/especially those most susceptible to its draw. It's strange that you're framing it as a strength and not a lament.
> There's no coming back from that world.
You can't say that when everyone just begs the question and shoves application-server-needed-here protocol designs to the fore.
There's always some Gemini protocol faction that shows up to yell that everything is wrong and we have to keep hand assembling our packets by hand or it'll never work.
Atproto's PDS is the root idea that everything extends off of, is the "social filesystem" that you control. There's a protocol objective to be able to spread your data around widely and for folks to be able to cryptographically check that that data came from you (even if you have to change hosts or even if someone sneakernets your data around). That's going to have some complexity! But it allows aggregation, is essential to how we are able to syndicate data so widely in atproto. It's so important it's in the name: Authenticated Transfer protocol.
And that in turn enables systems like Tangled here to be built, that layer stop the personal data servers, and relays. These work because there is identity.
If you need your static site to be on atproto (yay!), you can just have one of the various PDS hosts (such as Bluesky or eurosky or black sky or npmx) host the PDS for your. Since it is authenticated and user sovereign, you can permissionlessly move to a different host whenever you please, should that go awry. It's unclear to me why static site needs are an interesting or useful target that social networking ought conform to.
If you want to make a simpler network where we don't have those guarantees, please go right ahead. It feels to me like a snap reaction though that doesn't bother weighing what we have gotten or why things are this way, that is reflexively demanding.
> If you need your static site to be on atproto (yay!), you can just have one of the various PDS hosts (such as Bluesky or eurosky or black sky or npmx) host the PDS for your. Since it is authenticated and user sovereign, you can permissionlessly move to a different host whenever you please, should that go awry.
These seems to defeat the purpose of the relative amount of sovereignty that hosting a static site gives you compared to depending on a PDS.
> It's unclear to me why static site needs are an interesting or useful target that social networking ought conform to.
Your data is still signed by you, and you still have the keys to move your PDS no matter what happens to your host. Do you have an actual threat model or reason why you are so afraid / unwilling to accept any compromise?
Your lack of a reply at the end, refusing to support basically your entire ask with even a modicum of supporting cause, feels a bit vindicating, that indeed you are a hostile agent & not here to engage or discuss, but to throw bombs.
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.
Yes, all of those things are possible. Now imagine a protocol built from the ground up for those purposes, not just possible, but the entire community and ecosystem embracing those things.
We've tried that, multiple times. Semantic Web, "everyone has an API" and more before and after, none of them gain sufficient traction to stick around and be built on top of.
ATproto federates in a very different way than Mastodon. There is no concept of "instances" on ATproto.
Your account is hosted on a PDS and you sign into the app with your PDS sign-in and records go to your PDS, but everything on the app is from what's called an "AppView" which provides a centralized view of all data in all PDSes so it feels just like you're using a regular centralized app. But there can be multiple AppViews and AppViews can be self-hosted.
So unlike with Mastodon, it doesn't matter what PDS "instance" you're on because the app layer is completely separate from it.
Regardless of name and precise technical details, there are central service components that can ban you. If a proper ecosystem of those ever springs up then the equivalent of fediblock (ie guilt by association) oriented at individual accounts or PDS is the next logical step. At present (last I checked) there's only (approximately) one primary provider plus blacksky making the situation even worse.
This isn't some wild hypothetical - we also see guilt by association in the matrix ecosystem.
Most bans today are at the "appview" level: the big indexed view of all the data, that combines the firehoses ("relays") marks accounts as banned & doesn't show their stuff. But the relay and the PDS still work.
Agreed that there aren't many public appviews for Bluesky posting right now, really just the two. Tangled itself though is an appview, of a different sort: one not for posting but for git issues/pr's/rtc. This appview isnt gated on Bluesky or Blacksky's permission. And folks could pretty comfortably host Tangled aplview themselves, subscribing their Tangled instance to any of the dozens of firehose/relay instances, getting all pre-filtered Tangled activity. And that really is quite decentralized a model that is imminently doable. Regarding the technical properly, the concern here about banning feels premature & naive: it assumes Tangled depends on these appviews at all, and it doesn't.
I will note that Phil's constellation project just tackles the key reverse indexing that comprises much of the appview work: taking all the firehose records, and connecting all the threads and likes together. Constellation runs ok as a public service on an rpi. There's a lot of challenges to making new appviews, but it is astounding and comforting seeing the core indexing for a sizable multi-media social network running on an rpi. What seems like a dire situation may actually be opportunity, if folks actually tried.
Whatever problems we want to foresee dooming us, whatever slopes we want to hypothesize sliding down, what we have here sounds way way better than anything else available to me today. Personally I'm much more bright blue sky sunnier about the prospects rather than your dark raincloud doom fall scare-away. The risk imo is immensely more weighted in not trying more than trying.
I'm not saying people shouldn't build things, merely disputing the idea that the logical equivalent of instances (and the ills they lead to) don't exist on ATProto. Guilt by association currently exists as a fairly common practice on all the community protocols I've made use of - including federated, p2p, and whatever else - so I see no reason to expect it won't also infect ATProto.
The key difference is that ATProto currently only has a small handful of instances, ie it remains largely centralized. Certainly it's a blessing that the operators appear to have generally acted with benevolence to date but that's not really relevant to the point I'm making.
Don’t they already have extensive block lists that you can “subscribe” to? I think some official blue sky account was added to some and they got super mad?
That's an additional (but closely related) issue. AFAIK those lists work at the user level to filter what you see, so while they aren't a network breaking "guilt by association" practice they're a form of centralized, lazy, delegated moderation that has outsized impacts on any borderline cases or false positives.
Besides those appview block lists, relays also block stuff. I know relays block stuff because bluesky isn't being sued for distributing child pornography, as it would be if it didn't block stuff.
Comparing open source social to algorithmically based social is never going to work, that's like saying the Light Phone isn't as popular as the iPhone, so its a failure.
The question is, does it work for you ? If over time open social gets a toehold then it will be an option people know about and can choose.
Not in expert in either but ATProto services (what they call AppViews) are substantially different from the fediverse because they rely on a shared relay instead of explicit federation.
I'm conflicted about the costs of what is currently effectively global discovery, but it's not just another Mastodon.
E: I think its funny multiple other people said the same thing in the time it took me to write this
Note a relay is a perf optimization and doesn’t have to be a single shared chokepoint.
These days running a relay is fairly cheap (~$30/mo?), there’s maybe a dozen of them, and some apps don’t use one at all (instead relying on services like https://constellation.microcosm.blue/ for querying backlinks).
As well as a confusing onboarding where users have to pick an instance, something both incredibly important, but with very little info to base your decision on. Pick the wrong one and your project gets screwed when the random anonymous instance owner decides to shut it down or go on a power trip.
Resulting in everyone just picking the "default" instance.
>Pick the wrong one and your project gets screwed when the random anonymous instance owner decides to shut it down or go on a power trip.
You say this as if it happens often, but it's more likely that a smaller instance will go under because of costs, and there are tons of perfectly fine instances where this doesn't happen at all.
Also you can join more than one instance.
Also it costs very little to host your own instance.
This is not a problem that exists for most people using Mastodon.
I agree the onboarding process is a bit confusing but really it isn't much more confusing than subscribing to a subreddit, except your identity only exists on that subreddit rather than a separate account.
Which I would definitely agree is a flaw but not an insurmountable obstacle.
> - 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 correct side) on
Why do you have to take a side / take the correct side? Can't you either just not take any side or take whatever side you feel like and go with that?
On Mastodon, if you take the wrong side, those on the correct side will defederate from you. Not merely because you host (or don't host) the content they like (or dislike), but because you merely enable (or discriminate against) those who host that content.
Of course, all sides are wrong in somebody's eyes; so no matter what you do, you will be defederated from by at least somebody.
The way Mastodon works, defederation irreversibly breaks all follow relationships, without notifying those involved. If you disagree with the decision, you can migrate to another server, but you won't get your followers / followees back, not without everybody involved doing a lot of manual drudge work. This is just one way in which the myth of "users are free to do what they wish, if they disagree with the admins, they can migrate somewhere else" breaks.
To make matters worse, there's no way to see which users that you may wish to follow are / will be hidden from you if you choose a given instance. Defederation lists are a (somewhat open) secret; it's good practice to announce defederations, but there's no automated API endpoint to see them, so there's no way to answer the question of "who am I going to lose if I migrate from x to y."
> On Mastodon, if you take the wrong side, those on the correct side will defederate from you. Not merely because you host (or don't host) the content they like (or dislike), but because you merely enable (or discriminate against) those who host that content.
Ok, so? People block you all the time because they don't agree with you, why is that a problem? If people don't want to hear what you say, shouldn't they be allowed to not listen?
Personally, I don't understand that point of view of blocking people who you disagree with, for me the point of the internet is to find different views and perspectives, but I'm also fine with others filtering out whatever I say, doesn't really impact me either way.
If you want no rules what you say, run your own instance. Depending on what you say, some people will want to listen, others will want to filter your opinion away, I don't think either sides are "wrong" for that, it's just like in real life. If you want to use someone else's instance, you follow their rules. It mostly isn't harder than this.
No, because this happens on a per-admin level, not on a per-user level.
You go on a cruise for two weeks and there's a disagreement about whether to federate with Meta or not. Your admin takes a side, whatever that side might be. Two weeks later, you come back and lose 10% of followers, and there's nothing you can do about it.
Yeah, that kind of makes sense to me, you chose that instance because you're OK with that admin making choices for you. Just like how I choose to post comments on HN, and if the admins/moderators tell me to stop something, or that now half my comments are gone for reason X, I can't really cry about it, all I can do is follow what admins do/say or jump ship.
> you chose that instance because you're OK with that admin making choices for you
Nobody chooses instances for that, very few know anything about the admin, people just like the content until... in >70% of cases, bait and switch follows
That's why Mastodon is such an incredible mess, it creates the conditions for serious problems, then goes: "you chose what you knew nothing about, nor there's any way to know anything, therefore... you are the problem".
Yes, if you willing participate in an ecosystem where you know large swaths will be actively against you and try to defederate with you, that's kind of on you. Don't participate in that ecosystem if you don't like it, the ones already inside this ecosystem (like not me), seems to be OK with it and others outside of it (like me) seem to be OK with them having their own ecosystem where they can do these things.
Maybe I'm lucky in the instance I chose or the content I like being uncontroversial, but this isn't my experience at all.
I've heard of instances carrying a lot of Nazi content being banned, and of instances choosing not to re-host adult media (which makes the interface a bit worse, but doesn't actually block you from getting that). But most admins from what I've seen are pretty clear on this in the about page of the instance.
70% seems like a wild claim.
I have had content I like being removed from major social media platforms, like reddit and tumblr.
Also, if you choose an instance and it gets shut down, you just start another account. This isn't serious business, it's social media. To me, complaining about having to choose an instance to start is like complaining about having to choose a class at the start of an RPG.
Personally, I really love mastodon as a platform and I don't understand all the hate it gets here.
As far as I know, Mastodon didn't really set out to solve that particular problem. But it does seem like ATProto did, as it seems a lot easier to move around in ATProto than Mastodon (and ActivityPub in general).
You're complaining that moving away from a PDS means you have to let that PDS know you're moving away? Do you understand what you're actually complaining about, or I the one who misunderstand what you're complaining about?
> there's no way to answer the question of "who am I going to lose if I migrate from x to y."
Ahckchually, once you create an account you can use the API endpoint for remote lookup to test in an automated manner which nodes are and aren't reachable.
They'll then defederate also from you. The argument goes, you're a nazi/facist/racist/*phobe, because you associate with (== did not defederate from) the designated nazi/facist/racist/*phobe.
Yes, it's that toxic. Go subscribe #FediBlock hashtag if you don't believe me.
Ok, so what? Let those people block you then, sounds like people you probably don't want to interact with anyways?
I've seen that, and I'm not sure what's supposed to be toxic. It's community-organized filtering of unwanted views, for the people who want to engage in that. I don't agree with that, so I don't participate or do that myself, and I also don't seem to face any negative consequences because I'm not participating in that. What am I supposed to be sad about here, that some people don't want to listen to my views?
Witch hunts and guilt by association are generally seen as toxic. If you disagree with that I'm not really sure what to say as it's a rather fundamental principle from my perspective.
> sounds like people you probably don't want to interact with anyways?
That's all well and good when it's a single user instance or small group of friends. But often enough it will be a much larger one with unknowing participants caught up in it. Blaming them for choosing the "wrong" instance is about as productive as blaming people for using facebook - technically correct but that's about it.
That said, the AP model seems like the least worst to me. Every option I'm aware of has significant downsides.
>Ok, so what? Let those people block you then, sounds like people you probably don't want to interact with anyways?
The problem is when this is a large server with people you know using it. They suddenly disappear from your feed. And those people may not have even agreed with the reason for defederation.
At that point, the only way to connect with your friend(s) is for you or them to find new servers that haven't (yet) gotten into a defederation slap fight.
The TL;DR of the problem with Mastodon is that you basically need to pin your identity to what is essentially a small internet community/forum and then give them full power to decide who/what you can consume while your identity is tagged to their community.
Look, life is complicated and not a single issue, contrary to what admins of many of those fedi instances would like. Typical human has views on multiple subjects, but it takes only a single incorrect opinion expressed to have you ejected. Worse yet, it happens by leveraging the admin of your instance: they go to the admin and tell him/her that if you're not banned, they'll defederate the whole instance. IOW they're bullies, and bullies squared at that: they designed a whole protocol to enable bullying.
Again, go check #FediBlock. If you'd like a specific example of the single issue vs multiple issues, pay specific attention to trans vs black conflict there and see how it is played by both sides.
I'd like to preface I'm pretty active in atprotocol ecosystem, so my experience is more than likely a bit more biased, but thought I'd share some of my thoughts as a big fan of tangled.
I've really enjoyed Tangled. It has so far been what I've wanted from a GitHub replacement, is simpler and does not have as many features, but it has been the main social/git provider I've been using for personal open source projects for about a year now (this me https://tangled.org/did:plc:rnpkyqnmsw4ipey6eotbdnnf)
- It has a social graph connected to it I know from the social media I use (Bluesky), it's nice to put a face/name I may have seen to their commits/prs/issues
- Is nice it's login is the same as other things I use
- They have recently added built in support for static
sites, nice for those client side webites or simple index.htmls you want to host somewhere straight from your
git repo.
- Spindles is their build system/actions. Not a nix fan, but they do use some flavor of that and have worked really well for what I've needed
- An open API that allows me to easily render information thanks to being built on shared standards I know (atproto). I've built bots and wrote a few features into npmx.dev that uses various things from tangled easily thanks to that.
- Ability to run your own knot(git server) and runner (spindles), or easily use the ones they host, but the cool thing about this is the social features are separate so even if you have a separate git server the issues/prs/etc are all coming from that shared social layer, not like they need to make an account on it to partake in the convo.
It's not perfect. It has alpha in the navbar and does feel like that sometimes. I am missing some features, but all in all I've really enjoyed using it for my open source work and will more than likely continue using it going forward.
In what sense is bluesky irrelevant in this context? It's obviously not Twitter scale, but no alternative to GitHub will be GitHub scale for a long time to come either...
And it does seem to have the right feature set. Not sure which other social graph/network you could reasonably build a GitHub alternative around that would be less irrelevant....
It's largely perceived to be an ideological site. Obviously every community has its own biases and tastes, but I think Bluesky has just captured the imagination as the "left-leaning social platform." When the NYT was talking about a potential link between the WHCD shooter and Bluesky posts, that's what they referred to Bluesky as.
Obviously Tangled can live completely separate from Bluesky, it doesn't even need to share branding. Protocols are just protocols and people who don't understand how email works often don't even realize that Outlook and GMail use the same protocols. I'm hoping for this future personally where ATProto is only something the nerds care about (and write code for.)
(Please don't respond to this post with ideological argument. I'm just trying to talk about Bluesky and ATProto.)
That may be the case, but anyone can use ATProto. Unlike X where reach is suppressed for ideological motivations, or Mastodon with the federation turf wars, anyone can use it, regardless of their politics. If you disagree with the ideology of the majority users and avoid it for that reason, it just perpetuates the problem.
Unfortunately, I suspect it is only that way at present because the "other side" is perfectly content to continue existing in a communications environment that prioritizes them, rather than one that is actually open.
Unlike Mastodon? What's the difference? Anyone can use AP regardless of politics, you just might get banned from other's infra the same as for ATProto.
Fair enough! We are a pretty small ecosystem all in all. I will say in Tangled's case their infrastructure is separate from Bluesky's for the most part, and the rest can be switched easily enough if ever needed.
One example is if you don't care anything about atproto, you can create a new account on Tangled's website that creates the account on their servers, but thanks to how atproto works it's just like you made one on Bluesky and can still interact with Tangled and everyone on the protocol for it's social features.
We're not discussing social networks though, this is about Git project hosting. Bluesky doesn't have to compete with Twitter, Facebook, Instagram, TikTok or any of that for Tangled to be useful.
Those were all isolated places, where you needed an account for that specific forum (whereas you can use your PDS anywhere), where that forum held your data (whereas you hold your atproto data, and we all internetwork to see the aggregate), where you were subject to the moderation decisions of that forum (whereas you have control over your PDS (but not other people's clients)).
Pretty unclear what your comment is trying to indicate but it sure feels very different to me, and I've offered some characterizations for why.
More generally, atproto is useful for all kinds of tech, solves a cold start social network problem. Aren't we reinventing forums, and tv watching, and book reviews, and trail maps, and photo sharing, and streaming, and d&d, and key attestation, and file sharing, and publishing, and note taking and containers and git hosting? Yes. Yes we are. https://atstore.fyi
(Under a common protocol set, in a way that respects users unlike everything else that's happened online so far.)
Lots of negativity in the comments and while I'm as distrusting of VC funding as the next guy I think competition in this space is something we should encourage, and bootstrapping that is hard if not impossible at this point. Obviously this post was timed well with the 2-3 GitHub-hating posts that made it to the top of HN yesterday, but I commend the attempt here. I hope it takes off in a meaningful way.
> Lots of negativity in the comments and while I'm as distrusting of VC funding as the next guy I think competition in this space is something we should encourage, and bootstrapping that is hard if not impossible at this point.
What you are calling "negativity" are genuine concerns to me. I was excited at the headline first. But as soon as I found it is VC-funded, it became a complete non-starter for me.
Look, I'm going to make my labor of love available to the world on your platform. I'm not going to earn a dime from it. It's just free work I'm gonna put out there. If I'm going to do that, I'll choose a platform where I can be reasonably sure that there won't be a rug pull 5 years down the line.
The problem with VC-funded projects is that there is definitely going to be some kind of rug-pull. Because the investors need their money.
The Git hosting services I use today are those where I can pay as a paying customer or I can pay as a paying member. As a paying customer, I know what I am getting into. As a paying member, I have the right to vote on decisions that affect the platform.
I agree with everything you wrote, but wanted to add to:
> The problem with VC-funded projects is that there is definitely going to be some kind of rug-pull. Because the investors need their money.
If you can tell me up front what the rug-pull will be in N years, then I could potentially look past it for certain use cases.
But if all you say is "I know you don't like VC-funded companies, but ours really is different because of X" then that's pretty much a slap in the face to users who've been through the hamster wheel of enshittification before.
The thing with VC-founded projects is that there's some kind of rug-pull, ads, privacy violation or "feature enhancing" subscription likely coming and as users we should know.
I don't really like services that stress how idealistic they are when this is the upcoming reality.
Better charge money for services or if you're truly idealistic start it as a non-profit. At the very least communicate what's the monetization plan.
The big question is (and I don't know the answer, so not rhetorical) whether the protocol being open can be sufficient to prevent the rug-pull from being too bad...
If their technology choices are holding them back it just means the product becomes more turbulent as they desperately thrash for a way to make more money.
A protocol isn't a good enough reason for investors not getting their payday. They'll just force aggressive and reckless changes to see a return.
The only way this kind of thing works is if profit isn't in the equation, or the easiest path to profit lines up with what's best for the customers.
This is why I'm skeptical about bluesky in general. Despite the protocol, it's incredibly centralised. If they wanted to make money it won't be long before they start putting up the walls around their garden. The same thing applied here as well, if investors demand a return the open protocol usage will shrink or become less open.
When did Bluesky rug-pull? Seemingly they seems hellbent on making it harder for themselves to rug-pull, at least judging by the developments of the protocols and ecosystem so far.
> and bootstrapping that is hard if not impossible at this point.
What points towards bootstraping being impossible? Sure, it's difficult, that's almost in the name so makes sense, but impossible? Especially if you're aiming for the federation-angle, then you should be able to build cheaper infrastructure, not the same/more expensive.
>What points towards bootstraping being impossible?
Even just the security concerns and having any confidence in the implementation is likely a specialized skill, so you'll need to convince someone to work for free or be able to pay them. Now do that for other major lines of work like UI/UX, Ops, and QA.
Take a look at all of the features from GitHub or any code platform that you'd need to get people to sign up these days (because they are used to GitHub/others) and it's a very tall list. Think something like https://www.enterpriseready.io/ but definitely larger (maybe 2x, 3x as large).
Oh and if someone writes a long rant about it and it gets to the top here, it likely becomes dead in the water, and you can't get the time back, making it a risky proposition. At least with VC money, you got paid a salary.
You could theorize about all those things, or you could look at Codeberg, sr.ht or others that already are doing what you claim to be impossible, yet haven't took on VC money. People are signing up and using these already, despite not offering 100% the same features.
The aim doesn't have to be "Be the next GitHub", but something else, and that's just as valid and "successful" as anything else, as long as they survive as communities.
Understatement, probably. Your blog posts are so far the best introduction I've seen to ATProto. Is there any tagging I missed that collects them all in one place?
I don't think we need a federation of forges. What we need instead is just richer git repos.
Fossil gets 90% there with integrating tickets (issues), forums and wikis as part of the repo itself. When you clone a fossil repo, those are also part of the clone, and can be browsed offline on an airplane. Replies can also be written offline and, permissions willing, synced back up to the remote, either immediately or when the internet connection is regained.
I think this is the direction we should go in, but without hardcoding any specific artifact kind as part of the VCS. Instead, repos should be able to contain apps, which would define policies on what artifacts are acceptable, what rules they must follow, and who's allowed to upload and download them and at what times. The job of the forge would then be to execute those policies and render the artifacts for web users in whatever way the app desires.
With such a setup, moving to a different forge would entail nothing more than pushing the repo there.
Hey, so... Thanks for this. I've been building ticket systems and agents and whatever else as flat files in git repos lately and now I see I have to extend that to actually managing the repos themselves.
I still would like to be able to send and receive issues and pull-requests, to/from anyone.
Your idea here seems to be about how to encode the data. You talk about web interfaces & who is allowed to do what. But it's not clear to me how my repo/forge gets my PR in front of you. The social networking technology feels like it has to come into play somewhere, and I don't see that as described in your system.
The problem I feel with federated solutions is basically the 'cold start' problem.
When you are wanting to join a federated network, you have two choices: join a pre-existing server thereby creating the exact same problem you are escaping, ie: a giant server that holds you to its whims, BUT you do get a big network to begin with.
Or you start your own server but your network is zero, discoverability is zero, your feed is empty, and you have to convince other sites to federate with you / not block you for the crime of being a 1 person server / etc.
Am I alone in this feeling or am I just doing federation wrong? (But also this may just be a problem / quirk of Mastodon)
Yeah that's why Tangled didn't go with ActivityPub (Mastodon protocol) and went with ATproto instead, which is specifically built to solve that problem, so individual servers are all aggregated by centralized AppViews (that anyone can host) that give a singular unified "view" of the network that is just as cohesive as a centralized network feels.
ATProto simply ignores the need for decentralizing incentives on a human/community level. What we get is a sort of a "top-down" federation rather than a grass-roots one. Whoever invests in the infra ends up running a domain.
I mean, practically no one is aware of any other ATPROTO provider other than Bluesky whereas the issue with AP is merely the lack of better implementations, so mastodon.social got the most attention and the hype died off with niche success.
There’s no such thing as “running a domain” or “atproto provider” in atproto. You’re approaching it with a Mastodon/AP mindset and it doesn’t match that.
In atproto, there’s two axes.
One is hosting. Bluesky offers hosting but some people host on their own (it’s just a Docker container with sqlite), some on Cloudflare, some on community-hosted nodes like https://npmx.dev and https://selfhosted.social. From app perspective it looks exactly the same way (unlike in Mastodon where “hosting” = “choosing a community”) and you can switch hosting anytime.
Another axis is apps. Apps aggregate from data from all hosts. Bluesky is an app, Tangled is an app, Leaflet is an app, Wisp is an app, Semble is an app, and so on. Those can all aggregate over the same data (which enables cross-app interop) but they don’t have to (eg Bluesky doesn’t overlap with Tangled much except that Tangled can reuse Bluesky avatar on login). Generally you don’t have people running copies of the same app (as in Mastodon) which is why there aren’t many “blueskyes”. But when someone has an incentive, they can. (Eg Blacksky is a complete fork including server and DB, allowing their own moderation decisions over same data.) Similarly you can build your own app on top of distributed Tangled data.
Hope that helps clarify why “atproto provider” as a concept doesn’t make sense. You have hosting, which is as distributed as you want, and you have apps, which anyone can make.
So does Bluesky app have control over what data it aggregates and can decide (without checking with a user) not to aggregate data from a host? I am trying to understand what are the implications for a user, and a bad scenario where one would disagree with an action of the app.
And if the answer is "yes" then at least when someone "makes their own app" can they easily use "Bluesky hosts list" + add special extra hosts (or remove specific hosts) so that the app relies on the platform, with the exception the disagreement point?
An app can choose to ignore/ban some users (or even entire hosting servers if they’re specifically created for network abuse). This is similar to how any web app may choose to ignore POST requests from spammers.
And yes, someone can decide to aggregate data themselves and provide an alternative app over same data with different moderation policies. In fact that’s already the case (Blacksky runs their own application server that mostly piggybacks on Bluesky moderation decisions but overrides some of them. There are also clients that ignore moderation altogether and show you the raw data from hosting.)
Not really. From my understanding, in AP, your account belongs to an instance and your data is then synced to other servers. If the instance goes down, your account is gone.
In ATP, your data is stored in the "Atmosphere", hosted on decentralized "Personal Data Servers" (PDS). The app then simply parses and filters that data. They can apply moderation actions by choosing not to display or read certain posts, but your data still exists and another app could choose to display it. Similarly, if the app goes down, your data is still perfectly intact in the Atmosphere.
It might then seem like the PDS is equivalent to an AP instance, but as mentioned, they are decentralized. Identity is verified through signatures, so if your PDS goes down, you can migrate to a new one as long as you have your signing keys. Therefore, the account belongs to you and not any specific server.
You're interpreting my post with the assumption that I don't know what I'm talking about. You don't need to explain the protocol to me.
Domain here referred to the area of influence or control, like what the provider of a relay effectively has. The fact that other groups can run any element of the infra themselves doesn't change the fact that the drift towards centralization is much greater with ATP than with AP.
ATP has its own uses (quick aggregation) but it doesn't even attempt to solve fundamental issues of current ecosystem of social networking,. AP, on the other hand, offers the foundation for further development in the right direction.
A new hosting provider can preemptively request known relays to crawl it. Or relays (or apps) can lazily discover it when the user hosted there tries to log in for the first time, or their data is linked to by a known user. It’s similar to the relationships between websites and search engines.
Hosting providers don’t need to discover other hosting providers. Data only flows between hosting and apps; not between hosting and hosting or apps and apps.
I think the gain sits in the middle: if the giant server starts to get iffy (moderation, content, policy, technical issues), people can leave it somewhat easily and form or grow another decently sized server which will have enough reputation from day one.
We already have other decently sized GH alternatives such as Gitlab, Codeberg and various OSS forge instances (freedesktop, Fedora, Debian, etc) which could be federated and become a safe harbor if we were able to maintained project visibility and discoverability.
That's been entirely my own experience, or at least the assumption that's kept me off all of them so far.
But I saw this project a few days ago and thought to myself "Hey, this one could actually work." The difference here is that the target audience has a pretty strong overlap with the part of society comfortable with self hosting services.
I don't need my whole network for this one to be useful, only that subset that's actually most likely to show up.
The CTO @pfrazee had a lovely New Year's Eve post that talks about Atmospheric Computing and specifically raising the cold start problem and addressing how atproto tackles it. https://www.pfrazee.com/blog/atmospheric-computing
Tangled here is a great example. An existing user base of a social network was able to rapidly join and start using a new app, a git forge, to share repos and collaborate. PRs and comments show up like any other record on the network.
As for how the network works: atproto tackles the cold start problem by layering architectural concerns. Each person is their own server ("personal data server" aka PDS). But aggregation layers ("relays") collect all PDS activity they can find and relay it to consumers. Then applications such as Bluesky or Tangled ("appviews") can be built by reading records of interest (of the right "lexicon" type) from the relays. Each person owns their data, relays make all data available, appviews distill out user experiences appropriate to the records they cover.
Tangled is built entirely in the open: https://tangled.org/tangled.org/core, and our primary goal is to be "permanent software"—i.e. be fully reproducible and entirely self-hostable at minimal cost.
VC money is a means to an end. We're both Indian founders in Europe, and grants are nigh on impossible to find (4–12+ months for anything to materialize). VC is quite simply the quickest way for us to build a team, setup infra and accelerate development. We're also incredibly aligned with our investors on our goals (we took 6+ months to find the perfect partner for this).
Hey! Love the idea. I think a lot of skepticism here would be addressed if you discussed your plans to monetize. People just want to know how you will (eventually) make money in a way that is aligned with how they expect this to evolve.
In the latest FOSS project I’m starting, I’m not avoiding all “open core” supposedly FOSS projects. In my experience, they’re the projects most likely to do a rug pull and change licenses. If they cannot commit to their entire project being free and open, they are less likely to actually be committed to the principles of free and open software.
While I was quite excited about some of the ideas being discussed in this project, it being VC backed is a complete non starter for me. Your claims of being built in the open don’t make me feel any better, you will eventually need to make returns for investors.
How can they ever see a dollar of profit without a rug pull, license change or hosted moat? This is a neat idea - besides just replacing github, a network of loosely-federated git servers seems like a promising base for distributed social media or chat platform someday - but it seems like the only way it can really stay open is if you're planning to stiff your investors.
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 themselves themselves are highly complicated, and the benefit of simple bootstrapping is easily overshadowed if the software itself isn't friendly to being extensively hacked on by the average programmer.
I don't say you specifically have bad intentions or that VC money is all evil.
But now you need to grow fast, which greatly increases the risk for me as your potential user, so you should at the very least write a post to make sure you're aligned with your users not just with your angels.
How are you going to use the money? What's the business model? How do you ensure you're around in 10+ years? How are you going to please your overlords with that business model and what will you do if they force you to squeeze more money out of the business?
I hope you succeed, because the competition is good for users, but VC-founding is a liability not a strength.
VC money is absolutely not a means to an end, what is signals is that the company doesn't care about community and only cares about profit.
I'm with the OP you're replying to. Taking VC is an albatross that means a large portion of devs will never trust you or use your services (outside of bleeding your funds dry).
If this place truly cared about community they should have made a non-profit or some type of NGO, basically anything with a true community governance model. Not the current model of caring about money over a community.
We currently live in a society that solely cares about money and seriously doubt devs want to continue uplifting the current system that only benefits the rich at the expense of everyone else.
How many board seats does the company plan on giving to the community to ensure enshittification doesn't occur?
This kind of absolutism is crazy. People who are doing 90% of what we want them to do should be greatly celebrated and rewarded. Else we penalize idealistic people who are not perfect instead of penalizing the people who are actually doing the opposite of what we care about (ex. Autodesk).
Do you want software to become as closed source as mechanical engineering? No! So let's celebrate people building software that's open source, even if it's VC funded! They are awesome for doing that!
The problem with VC-founded projects is that there's some kind of rug-pull, ads, privacy violation (e.g. using repos to train AI) or "feature enhancing" subscription likely coming.
As a user who would need to invest time and effort in using Tangled, I think it's fair to ask to have the plan explained. I'd rather see explicit price for services than see enshittification happen.
Just like engineering, monetizing is an iterative process. As long as they don't make it hard to move off their platform, IMO it's completely fine for them to try different monetization models.
We should celebrate people building open source stuff and in the public. The alternative is for the software tooling ecosystem to look like EE or mechanical engineering tools - all closed source, proprietary, and with super expensive licensing.
It's easy to take open source for granted - 'information wants to be free', but we are at risk of the open source movement dying with proprietary AI completely changing everything about software.
If we penalize people who are working toward the right goal, we contribute to that decline.
You're badly missing reality here. There's no "community governance" as there would be in a local farm shop or something. It's a bunch of online people with interests. They aren't going to visit you if you're sick or coach your kid's team or attend your funeral.
The two reasons actual communities work in actual locations are: 1) because to some extent the people all live in a place and want the place to be nice for them and their (grand)children, so they are invested personally and 2) companies aren't set up to help communities. Communities are the ones doing community things. It's crazy to demand other people do work in a certain way when you're doing nothing.
> the company doesn't care about community and only cares about profit.
There are plenty of examples of VC funded companies that care about community & don't "only care about profit". Bluesky is a good one (literally a community / social platform). That's such a black & white take it baffles me.
> Taking VC is an albatross that means a large portion of devs will never trust you or use your services
A "large portion of devs" (the majority) use so many VC funded services? Probably _most_ services devs use are VC funded. GitHub itself - was VC funded.
You can have an anti-VC opinion but you have to also live in reality.
It's not about VCs being scum but about investors needing a relatively fast return on investment which is understandable but also often times incompatible with investment in large scale, open source infrastructure.
Would you be open to sharing a version of your pitch deck? The main question in my mind is what kind of exit the VCs have in mind when they give you this money.
Those of us who use it. Tangled is a neat project and architecturally it makes a lot of interesting choices but code-wise it's relatively simple and from my personal forays in it I'd say pretty easy to maintain.
The majority of the codebase is loosely related go modules. Then some static HTML+CSS. And finally a small sprinkle of typescript to tie things together. And of course a bit of Nix for orchestration.
IIRC it all runs on a pretty trivial amount of hardware that a single person could currently host by themself.
Users' knots, spindles, and PDS (plus atproto at large) do the real heavy lifting infra-wise.
Exactly. I'm personally slowly working on my own parallel "appview" of tangled that is accessible exclusively via SMTP, IMAP, JMAP, and eventually integration with a Lore + Patchwork frontend.
I don't think that will work. How many of us did contribute a simple patch to LibreOffice, Firefox, or GNOME?
At least this statement doesn't hold for LibreOffice. Their Online version, including "simple" HTML/CSS components, was archived because of a lack of maintainers. For their main project, the vast majority of contributions in the last release were made by former ecosystem partners (Collabora) or TDF staff. Volunteers only did a fraction of the work [1].
> Why does it need VCs? Why not company and corporate sponsorship like Ladybird?
You talk about corporate sponsorship like that's trivial to find. Trust me when I say we spent over half a year chasing down grants/sponsorships only to be met with closed doors, extremely long wait times for pennies. We'd also be required to keep our day jobs—which means less focus on Tangled dev, and ultimately very slow progress overall.
We debated VC heavily (we're both idealists after all), but figured we can make it work—it's ultimately the founders that make bad calls leading to enshittification. There's plenty of examples of VC-backed companies that haven't enshittified. Tailscale is an excellent one, and hence we brought on Avery as an angel in our round.
Sure Tailscale is an excellent one. For now at least. It is also not open source and also has a paid product.
Perhaps maybe in a few years time, Tangled Enterprise would be available to compete with GitHub Enterprise and that is where the switch over happens for companies who want to move over from GitHub to Tangled.
I don’t know because somehow Tangled would need to make money somehow?
I hope Tangled becomes profitable enough to withstand enshittification, because more and more funding rounds and not meeting targets means giving up control and facing a repeat of what happened at Bluesky.
Forge federation seems like a bad idea to me. If you want to go the route of decentralized project management (note that git as a VCS tool is already decentralized for this purpose), you're probably much better off modernizing the git-over-email workflow instead.
Decentralizing the code isn't an issue; cloning repo's between servers is so standard that any forge can import a code repo from any other forge.
The difficulty is ancillary stuff like issue trackers, wikis and MRs, but using a federated protocol for that seems ill-advised given the much weaker safeguards against spam. Mailing lists have a very large existing body of work on the matter of dealing with spam and a proven method of mirroring/archival. (Most git wikis are just git repositories with a different renderer.)
The main reason nobody likes doing git-over-email is mostly just because it's very user-unfriendly to set up (since modern mail clients typically aren't correctly configured to deal with them). It's a very developer oriented workflow in the worst way possible. A modernized mailing list program that automatically takes care of things like reformatting emails/not leaking email addresses to the general public would go a long way to make it easier to deal with.
I had never done the PR-over-email thing until I got an account on SourceHut; it was a bit of a chore to set up, but not that hard, and it did make me feel like it's very clearly the "correct" way of doing things.
"There are 4 standards that try to solve this problem, its too many, we need one that finally unifies it all and solves the problem once and for all"
"There are 5 standards that..."
Jokes aside, I think we need stronger arguments as to why something like activity pub is not good enough to solve the problem instead of trying to come up a new way of solving the "decentralized comms" problem.
ActivityPub and atproto are differently shaped. Pitting them against each other is like asking “why need web when we have email”.
ActivityPub is email-shaped. Servers are inboxes sending messages to each other.
atproto is web-shaped. User repositories host data (like personal sites or git/RSS), while apps aggregate from repositories (like Google Reader).
Different topologies lead to different properties. Eg atproto lets user change hosting with no disruption in app experience. atproto also lets anyone build new apps aggregating over existing data.
ActivityPub doesn’t allow either of those things. It’s literally a bunch of small centralized coupled hosting+app services messaging each other.
Calling AP services a bunch of small "centralized" services in this context removes all the meaning from that term. You might as well call any web server centralized while comparing them to clouds.
Proper federation is exactly such bunch of small services messaging each other. On the hand, what ATProto leads to is at most a handful of large-scale providers each running the own portion of the network.
There’s a clear difference in architecture between
1) a layer of app-agnostic hosting providers + a separate independent layer of apps aggregating over data from those (like personal sites with RSS + aggregators like Google Reader)
2) a circle of flat instances where each node couples app+hosting (like many little Twitters)
One doesn’t couple hosting with apps, another one does.
Mastodon/AP model is (2), atproto model is (1). You should be able to see the outcomes from different network shapes.
In atproto, you can build a new app that works with existing data, but in AP you can’t. In atproto you can move hosting with zero effect on your identity or how you show up in apps, in AP you can’t.
That's become my answer to all "why not ActivityPub?" questions.
AP isn't completely stagnant but there's a reason AT is still holding on to and accelerating that early developer excitement AP had. Maybe it's marketing, maybe it's money, maybe it's some technical thing. Maybe it's the community. Whatever it is, people seem to enjoy developing in the Atmosphere in a way I never saw on AP.
its linked in the original post as well, but here is an explanation of why activitypub is not a good fit for this problem, by the authors of ForgeFed themselves: https://forgefed.org/blog/actor-programming/
Reading that - I'm really not sure that AT Protocol has a much better story there either.
(as I understand it) the data has to live in a PDS, PDS are keyed by accounts, so you are similarly stymied for collaborative projects? I guess AT Proto is still a real work in progress so maybe that story has improved since the last time I checked it out.
Yeah the problems they seemed to have were over collaborative data structures with permissions. You’re right about how atproto solves that, which means you’re using CRDTs if you need to collaborate. If that’s a fit mismatch, I’d tell people to just appoint api servers which wrap a repo and provide the needed semantics.
Why? I really don't see the purpose of a federation of git repos. Git is already totally decentralized. 99% of projects only have a small list of committers. Tangled just doesn't solve an actual problem. Github was used because it was an easy to set up, free, place to store code and share it, and it had source viewing which was a step up from sourceforge. With multiple solutions available that makes this easy, its just not necessary to federate anything. The common user account part of github just isn't critical.
How do you discover new software using GitHub? Let's say I want an RSS reader for Linux - how does GitHub help me find one? I must have never used this part of GitHub.
Github has search functionality and grouping of repos by topic, etc. So you can browse repos related to a specific topic. Or you can click on someone's profile and see the projects they've worked on and maybe one of them is interesting.
I think initiatives for forge federation are trying to do too much. When running a forge for a project, I'd don't want to be dealing with spam or large amounts of data from other instances. And people should be able to report bugs and upload attachments, without having to give permission to share those with other instances.
A good system to download and migrate issues and pull requests is important, but that doesn't require federation.
I would love to see a smaller scoped federation of:
- Forks across instances, including for the purpose of PRs (Git)
- Activity feeds and notifications (Activity or ATproto)
- Authentication and some user settings (OAuth)
Because we are headed into a world where attacks on project hosting are more common, and loss of issues/PRs can halt a project while setting up an alternative and attempting to restore archived information.
The attacks span from forged DMCA takedowns, to national blocking orders, to suspicion that a contributor is from a sanctioned country (whether they still live there or not), to rogue project admins, and some other more creative attacks.
Project infrastructure should be distributed, with copies of data in as many computers as possible, across as many jurisdictions as possible.
It's easier and enables more features to have 1 common platform.
For example, the social features of GitHub, which I like (like stars, browsing repositories by tags etc..)
But also For PRs, the way to make a pull request to a repo hosted at A, from your own node hosted at B.
And like other commenters said, you can do this workflow with git over email like a lot of projects to, but the main goal of the federation here to me is the user experience, the UI being able to link all of theses separate repositories, issues, PRs, etc, like everything was hosted at the same place.
The basic idea is that you can put your repository on multiple GRASP-compatible nostr relays (GRASP is a sub-protocol that glues nostr and git together), so even if one server goes down you can transparently sync using the others. This means in effect 100% uptime if you choose reliable servers, as well as cryptographically-signed repositories, activity, issues, etc.
i can't speak to gitea, but github and gitlab are explicitly mentioned as having a license in their policy:
> Please be aware that GitHub and GitLab are exceptions to this Policy because they are subject to explicit licensing arrangements that pre-date, and thus take precedence, over this Policy.
i am unable to access any repository on that website. for some, it complains that ssh or https URLs are not supported by my browser? and for others its just loading indefinitely with `Failed to load file tree`. maybe its not fairly mature.
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 complexity of a "forge federation" system.
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 find software from any host – like ForgeFed would.
There’s also the concern with the friction created by requiring newbies to log-into a dedicated forge for contributions (which ForgeFed solves), but I reckon that’s a secondary and related concern.
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.
The only time I ever search GitHub is when I'm trying to debug or understand some esoteric API (usually Apple-specific) and I'm looking for anybody else who has actually used the god damned thing.
If I'm looking for software/libs/etc, GitHub search is the absolute last thing I would even think to look for.
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. Federation may solve it, by staying closer to the decentralized philosophy. That's my read.
Not sure I understand, you're talking about mirroring git repo data between multiple different nodes? That seems unrelated to what's proposed in the OP--maybe you're seeing something I'm not?
How does that fix "when one node goes offline you may not have any upstream to pull from"? You'd still have your own local copy—just like git—but you wouldn't be able to access any sense of "upstream"
You may ask, well, that's like hosting forgejo or any other git server, where is the federation?
Tangled uses a protocol. So knots would adhere to that protocol allowing to pull from any upstream.
That's my understanding of federation. not saying tangled will go as far as figuring out discovery across their cloud hosted knots and self hosted infra. But that can be done, and claiming to be able to pulling from any repo with a single identy would imply just that.
The biggest problem IMO is discoverability. I need an easy way to find open source projects that are on scattered servers. GitHub project search is limited to GitHub.
Events in atproto speak are changes to metadata/records, i.e. repo/MST events on a PDS.
So for tangled that means federation of issues, PRs, comments, follows, stars, and anything defined in an atproto lexicon. i.e. everything except the actual git repo itself. Those repos are singularly hosted on a given knot for the time being.
Now it's not a huge leap to imagine extending functionality to support cross-knot mirrors but that's not a supported feature yet. And of course you can always just fork a repo instead.
Github is already in practice federated, within the confines of github. If you fork a project you now have your own federated git forge with that project.
The difference is that these same flows should work without needing to be github to github.
That sounds more like you want better decentralization, like IPFS or BitTorrent, not necessarily federation between different forge instances. I'm not familiar with any existing federated system that would be resilient to government censorship. Certainly Mastodon and Bluesky aren't.
Usenet is, Matrix isn't. Usenet achieves this with a broadcast design - every node on the network receives every message. As a result of this and being flooded with half a petabyte of new messages per day, there are approximately 3 (three) nodes (all other providers are reselling access to one of these).
The text side of Usenet is healthier, with a few gigabytes per day, and not trying to retain every message forever. Would it work if it was also the world's git forge though?
- 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 personally I'd rather have a single account to manage -- and the AT protocol means that any individual forge can go down, but the data remains accessible from other AppViews.
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 already pull-based. We don't need another protocol to listen for changes at a URL. The web already has support for different content types and document schemas, we don't need to reimplement content types and schemas as ATProto "lexicons".
You're right. RSS builds on top of the web. ATProto does not. I'd say RSS is a resource format / content type, not a communications protocol. A resource format intended for syndicating updates – exactly what ATProto and ActivityPub do (but decided to invent new formats instead of extending RSS/Atom. JSON all the things!).
It is very much about identity. To use tangled you need to use ATProto and authenticate using ATProto – rather than using the existing open standard for authentication used by pretty much everyone at this point (missed opportunity to login to Tangled using GitHub). What's crazy is people still use the web to interact with tangled anyway.
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.
A federation doesn't mean the forges talk to each other. It only means there's more than one, and data flows between them. This can occur by developers pushing and pulling from different remotes. You already have a different remote for each fork, you lose nothing if they're also on different servers. Communication about the project can also happen in many places.
It appears that git format-patch + git send-email is a mature and widely used approach. Wouldn’t it make more sense for the open source community to work on streamlining that process instead of trying to build momentum with new approaches?
For what it's worth, under the hood tangled is extremely similar to this approach.
Personally as just a random person in the community I've been building an appview for tangled that lets you interact with it as if you were just using git format-patch + git send-email + some MUA.
You can conceptually treat the tangled lexicon as a schema for encoding a git patchset based mailing list into IPLD/atproto records and vice versa. Doing this is slightly lossy but only barely. Otherwise it's pretty seamless.
Tangled is pretty cool. I'm not particularly into atproto, and I think the connection kind of distracts from the reality of what it is and can do.
You can host your git repo on their servers, or your own. You can host issues/pull requests/runners/etc on their servers, or your own. Regardless of where a repo is hosted, you can interact with it from a single account, and with that same account interact with others' repos connected to tangled. Plus it has native jujutsu support, though you can use plain ol' git if you want to, too.
Do I think a forge with those features necessarily needs to use atproto to exist, or that atproto is the ideal version of itself? No, not really. But the site is there, and it has some pretty neat features I want; I don't need to love the stack to use it, any more than I do Github's.
Pretty much every word in English seems to have an innuendo meaning to someone, do anyone truly care past the age of 15?
I find Tangled's language a bit annoying because I'm pretty sure if this caught on it's even more single word concept rather needlessly. If the protocol is called Knot, then call a server a Knot instance or Knot server. If the runner protocol is called Spindle, each server which responds to that could be a Spindle runner. That'll serve two functions: It'll let people contextually hook the terms up against existing terms and still retain the option of evolving into singular word concepts if they prove successful enough for that to happen.
From my point of view as a non-native speaker, the frequent overloading of commonplace words add to the confusion of learning English. I don't like that. It's far from a big hurdle, but just big enough to earn a soft little sigh from me.
Your comment was the only thing that made me even care to comment: Isn't it rather unlikely that the person you're commenting on takes issue with a kink rather than any other reason why "knot" and "spindle" might be poor choices? Who knows, they might even have a good reason, but you started out with assuming bad faith and at least I tend to just leave conversations at that point.
I like their build system, is very simple to use, based on shell scrips, and has some neat features, like ssh-ing into the machine that had a failed build, or spinning a build with a custom manifest file (useful when you need to iterate quickly).
Although it doesn't have all the "plugins" and other stuff that CI tools have today, it provides fairly "standard" points of integration
I agree the website is a bit confusing at first, but after spending a couple of hours on it you can easily see how it's organised, for example to display branches and files it uses the more basic git terminology (e.g. main branch -> tree, list of commits -> log, branches and tags -> refs)
It's not a clear one-way trip though. The "original" blogosphere of the 2000s was heavily federated with MovableType supporting trackbacks and then later systems automating that further with pingbacks. Ultimately it all fell to spam and hosting complexity though, and now almost all blogs are on a handful of centralized hosts again.
Spam/moderation is going to be the biggest hurdle to overcome with any distributed forge effort. It'll likely come down to some kind of web-of-trust/vouching system, but it's delicate balancing ease of access with not making it a slog to constantly manage spam.
At least with atproto, we can see if an account has history and activity, see if their public data looks at all legit. The ability to deal with spam and disinformation seems so much radically better than anything else we've been able to work from.
Is Mastodon successful enough to be called "the future" of its niche? MAU is 1/3rd what it was at the peak, and bluesky + mastodon MAU combined is microscopic compared to twitter (I use none of these services, no dog in this fight, just looking at numbers).
GitHub is a huge and almost 20 year old company suddenly experiencing massive scale growth as a result of an externality it didn't cause and that no one predicted. That is an incredibly difficult scenario for any long-running, established organization to handle.
Yes, GitHub is temporarily breaking under the increased load, yes, it's likely to still be a thing in 2 months, and no, it's unlikely to still be a thing in 12 months.
It's very unlikely a cool new thing will peel enough developers off GitHub in the next six months to survive long term as GitHub inevitably gets its ability to handle the new normal scale back.
I used JJ for a bit, but I personally really, really dislike the anonymous branch approach it forces you into.
Branches are just useful conceptually, at least to me. For the same reason I like my documents grouped into folders.
Frankly - I think JJ just ended up taking up far more mental bandwidth than git. Simple operations need generated ids, commands require complicated input (ex - the entire revset thing), I have to be constantly thinking about the tool and its structure.
It feels really oversold to me. It's solving problems for people who live in source control, not problems for people who just want snapshots of code every now and then. Hell - just look at some of the example commands from the suggested tutorial:
With all due respect, if the intro tutorial to your tool includes a command having to literally write function names in quoted commands, or run a command with fucking 8 (EIGHT!) arguments... You've jumped the shark.
Not trying to harsh anyone's buzz - if you like it... great, it's clearly quite powerful. But it misses the mark for me. I want "just powerful enough" with minimal mental overhead.
If you cherry pick complicated commands, and remove all context, sure, they look cryptic.
I wrote that tutorial, and literally only one of those is relevant to my day to day work: jj new o, which means “make a new change on top of the change named o”. Yes, if you remove the context that “o” is on your screen and highlighted, it looks complex.
It’s the same with the other “jj new” command: you’re producing a merge by giving it every branch you want to merge together. If you’re merging five branches into one, you need to provide five identifiers for those branches. It could not be simpler than this. And -m adds a message, same as git.
The other two are showing off the power of the revset language; you’re not typing this stuff in yourself more than once, and if you are, you use an alias so that it’s shorter and easier to use.
> If you cherry pick complicated commands, and remove all context, sure, they look cryptic.
Sure I'm definitely not playing fair, but I am cherry picking from the intro tutorial you put together, so I'm not going crazy either :P
I think my primary issue is that jj feels like it wants to control how I work more than git does.
Mentally - I just don't want to have to think about changes as often as jj seems to want to think about them. And maybe it's an intro phase, or a thing you eventually build past (I only played with it for a week or two) - but it felt like a lot of focus went intro structuring my work, instead of doing my work.
Basically - the vibe I got from it was: if you're a person who really likes making checklists, or complex tickets with subtasks and groupings and labels - jj is something you're going to like. If you're just interested in writing code and not so interested in source control outside of the ability to occasionally "snapshot this folder"... it's probably not going to be your thing.
> The other two are showing off the power of the revset language; you’re not typing this stuff in yourself more than once, and if you are, you use an alias so that it’s shorter and easier to use.
This is exactly my point. I use git every day on the command line. I have ZERO aliases for it (seriously). If my source control tool has reached the complexity where I feel like I need an alias for commands in it... it's gotten too powerful. And git is definitely not "off the hook" here, it's absolutely got the same deep end, and if you live in that space, sure - jj might be really nice. But I strive to avoid living in that space.
basically: I don't want to do jujitsu, I want to do the occasional somersault and call it a day.
So, as a long-time mercurial users, revsets in jujutsu were a major feature for me.
And if you don't want to use them, don't. But if you are looking to treat your VCS DAG as a queryable database they are awesome. And, they are great for avoiding having to chain a bunch of commands together, inefficiently, to get the same effect. Although you still can do that if you really want to. Just like you don't have to use jq to query JSON - you can do terrible cursed things with grep and awk and sed and it'll even work for simple cases. But you might want to give jq a spin - and really there are strong parallels in how they work.
> Basically - the vibe I got from it was: if you're a person who really likes making checklists, or complex tickets with subtasks and groupings and labels - jj is something you're going to like. If you're just interested in writing code and not so interested in source control outside of the ability to occasionally "snapshot this folder"... it's probably not going to be your thing.
This is a bizarre take, as most jj users just take your paragraph above and do a s/jj/git.
The benefit most people find in jj is that you can do stuff easily without having to think much.
There is no separate concept for stash and index (and yet you still have them in jj, and use them without giving them special names).
In principle, there's no real distinction between merge and commit.
You don't need to know the difference with/without --hard for git reset. You just do a "jj undo" no matter what.
Merge conflicts are not stress inducing. And if you're in the middle of an ugly merge conflict, you can just say "Screw it all" and quickly get back to before you did the rebase/merge - just keep hitting "undo" until you get there.
jj literally has a much smaller cognitive overhead than git does.
First of all: you do you and as long as you are happy, I am happy.
`jj` is a tool trying to amplify the strengths of git and strengthen its weaknesses. `git rebase` being just one of the many quirky commands. Yes, `jj` requires some rewiring of your brain, but once you get over the initial bump its pretty slick.
Also, I use `jj` everyday exclusively. And I have written `revsets` like 4 times in total.
i mean i can throw a million cryptic git commands at you, too (jj revsets can be arcane, but they're also fairly well-documented and the names are fairly descriptive). git's gotten a lot of usability features over the years, but there's still a ton of stuff that's just confusing. jj ends up being a lot more intuitive in practice IMO, though the anon branch thing does take some getting used to. there's a lot more i'm comfortable doing in jj, without that 'defusing a bomb' feeling complex git operations often had for me.
Is there really nothing like BitTorrent for git, or have we just not heard about it because of GitHub's network effects? It feels like this problem was solved long ago for binaries.
Yeah I’ve met the Radicle people a couple times. I’ve never given it a thorough review but, for their goals, their designs have always seemed strong, and they’re pleasant people to chat with.
The main difference was atproto wanted to tackle scale, so we went with a servers & aggregation model. Radicle is going for device-to-device networking as a primary goal.
Do you think it will be possible to use them together? Having some sort of unified distributed system is intriguing to me. (e.g. can the Radical foundation and AT-proto foundation integrate, even?)
gittorrents were talked about and built at least 15 if not 20 years ago.
the issue isn't mirroring of data, this is a solved problem. everything else that a forge does is a problem - issue tracking, PRs, reviews, CI/CD, authn, authz, secrets, audit trails, ...
BitTorrent also enabled search engines to be built easily, which created discoverability. Unfortunately it's a much harder problem for git repos, especially when competing with GitHub search.
Git is already distributed by itself. The management-part is what's missing (mergerequests, permissions, issues..), and it's disputable whether this is really necessary, or just a nice to have.
I'm confused on what exactly we need to add to decentralized git to get where we want to be - if it's identities, why aren't we using what git itself supports (gpg keys; if someone has your private key, they are you no matter where)?
Or in other words, what specifically does GitHub "do" that can't be done by using git as a backing store?
As a project member, I want users to already be logged in to the bug tracker. The lack of friction, likely from being the network effect winner, is key. I know fossil has this, but people don't have their private keys in fossil, they (I) don't even have fossil installed.
Whatever happened to OpenID, anyway? That was supposed to be federated one-click login. If the problem is login, then only the login needs to be federated, and this approach leaves the rest of the system more flexible as sites can have different bug tracking features without becoming incompatible with the federation.
I think it's just nice to have things in a central place ; no one's really gotten decentralized tech right and things like discoverability, interaction, job running, etc. is really nice to have in one place.
Mastodon and email are the closest I've felt to a distributed system that works, but for oss stuff ... I think we're getting closer, but it's still a very hard problem to solve.
> how would you build a social graph of follows/stars and what not using user-owned git repos as a backing store?
I'm just spitballing and depending on how you want to display it, you may need more - but if I want to "follow" you I submit a signed commit to your "follow" repository, similar if I'm staring a repo; and then your system issues a signed commit back to my "followed" repo.
People need more than a VCS. A way to search all of open source project's code, issues, and pull requests. A way to distribute software releases for free. A way to share code snippets. A way to discover new projects. A way to see what your friends are working on. An issue tracker and pull request area that is easy for users to submit through.
Last time I tried Tangled they had no concept of private repos. That’s the only thing keeping me on GitHub (oh, and my massive likes collection, I use those as bookmarks).
I’m self-hosting with cgit, maybe I could move my private repos to SourceHut? Idk.
Crazy... I actually hashed out a plan to begin bulding a successor to github earlier this week and this blog post describes EXACTLY what I was thinking about with atproto+git.
So you could theoretically either fork it and use it as a good starting point, or (even better) contribute the ideas you have straight into Tangled itself! :)
Can't we really go back to pre-github model? I mean all it did was to reduce the barrier for contributions. With current flood of AI generated PR it doesn't sound like a big inconvenience to have to register at code hosting service used by project you want to improve/participate in.
I really don't understand this fear about a single pillar of failure, as people were in tears about the Ghostty thread yesterday. git is not GitHub. git is not HTTP. git is inherently decentralized with no concept of client/server. In git there is only local and a plurality of remotes.
That said the solution is simple. Open a secondary, or a new primary, account with another provider and add it to your project's list of remotes. Here:
Boom, problem solved: do it yourself redundancy/decentralization. If you want to make this federated then write a file containing a variety of remotes per addressed location and a script to dynamically update git according to your catalog at every location.
Not if your CI depends on github, or if you have specific actions to review things, or if you use SSO because you're an enterprise, or....
Workarounds exist for each of these cases, but they add significant friction. That's not terrible if you're one person, but if you're an org? big problem.
Most enterprises self host for all those critical things so they aren't blocked by third party service interruptions. SLAs might refund some money, but they won't recover the lost time.
I think this is less about source code itself, and more about the surrounding ecosystem of project management. Handling of issues, pull requests, who gets commit or admin access, all that stuff. If you mirror your git repo to other providers, fine. But if you have thousands of issues and PRs on Github, you still can't really move away and you still can't really work if Github is down.
Edit: I absolutely support federated forges, including Tangled as well as ActivityPub based approaches like the (slow) progress to federate Forgejo.
Pull requests are a core feature of git, the protocol, so I think you probably mean certain PR features more than just PRs.
Issue trackers can be self-hosted from fully mature applications via docker images. You might find something here: https://selfh.st/apps/
CI is typically actioned from a configuration file in your repository to a CI SAAS solution, which could be anything. Travis CI was popular for a long time. When I was big into CI SAAS my favorite was Semaphore CI.
I was just thinking about forge federation this morning. It'd be nice to base the federation on email, which has been working fine for decades (boring tech and all that), and build UIs on top of it to facilitate collaboration.
Lovely, so yet another promise to federate which will never materialise! Still going with the Drew’s reply in https://is.gd/5wwQy2 (yes, two years old, and he slightly softened his stand since then):
> SourceHut is already federated via email. We have no intention of adding ActivityPub support at this time.
Federated repositories is something very similar to paperless office, distributed authentication (OpenID), and distributed computing … it has been promised since forever, and nobody has ever seen it in the real life, and even less supported by somebody who matters. And yes, those who matter don’t help by sabotaging any efforts towards it.
Devault being a gigantic dick head has no bearing on whether or not tangled does things. If sourcehut wants to remain the isolated hermit of forges because the greybeards that be think it was better before, let them do so and remain their island of weirdos. We already do the same with the freebsd guys (except that freebsd is actually good and impressive unlike sourcehut)
Sourcehut does not matter, and federation of repos is already a real thing. The ones that don't want to federate just.. don't?
I really like the concept of federated social networks and it's the next thing I want to get into. Maybe even work on it as a job but I doubt there are any that pay well.
I think sovereignty over what information you consume is more important than ever. I had to use Twitter for work to get news about <topic> but the amount of virulent propaganda, totally unrelated to <topic>, that you end up absorbing is unforgivable. Even if you think you're smart and don't pay attention to propaganda, by design it hits you at the subconscious level so you can't block it. The only social media I have left is LinkedIn and I really hate it but it has made a direct positive material impact in my life ($$$) so I try to hold my nose while I use it. I really would rather use some kind of federated LinkedIn, but when I last checked nothing like that existed yet.
The snapshot-based system requires that the patch order matters which Darcs/Pijul don’t require so long as the patches apply since they commute. This means you can pull in patches from other users at an time in any order & still get the same stable reference. If you apply patches in a different order in Git, you will get a different reference hash & some entity ends up needing to be the centralized source of truth when doing deployments & stuff—which is probably why everyone ends up having some code forge for their code base on a centralized server to “sync” the state.
And with rebase, how are the commits immutable? Seems like MS GitHub found a way to mutably drop commits recently…
Oh! Posted some replies here, but: I forgot to mention one other incredibly awesome atproto based social coding decentralization system! Jeremie Miller's v-it, which lets folks share "caps" changes, "vouch" for each others caps, share skills. https://v-it.org/
It's so so so early. But I love how it moves from a world of maintainers & pull requests to a more ambient "this is what is working for me". I think this really is a next kind of leap. I don't know if we can keep relying on maintainer folks to guide each project forward like we have, if our agentic selves can be bandwidth limited & still go where we need to, channeling all our energy through individuals.
We need a federation of maintainers. A distributed of maintainers. Maintain ought be social. Tangled is great and I hope we can go beyond federation to many tangled, to widely widely tangled. And I hope we can go past maintainers too, past pressuring single people to have to decide it all. I think v-it really preceeda such an interesting agentic leaping off point that we are at, so interestingly.
This looks cool but the issue github is dealing with is exponential usage. They're trying to 30x their capacity right now - let that sink in! Microsoft here or there, any company would be struggling under this load. And I frankly don't think that any ideology driven alternative will ever be able to provide better uptime under the same load - or any alternative period, for that matter. We're just living in times where everyone is catching up with the capabilities of agents, and it was obvious that things like this will happen 12 months ago. Good luck for your project though!
I agree that any company would struggle in such case. The thing is that everyone see that GH is pushing for more agents, their Copilot thingy, and AI everywhere, while basic functionality that people relies on is constantly failing.
If you push a lot of new features but your baseline is constantly failing, then something is wrong.
If you're seriously using agents, you'll know that if they didn't offer that then people would rapidly switch platforms if they didn't. Maybe not all of them yet, but soon it will be all.
Switch to a git provider that offers agentic augmentation of your workflow. And I don't necessairly mean the way it works right now - it's being refined & adjusted & infrastructure is being built as we speak.
For example, in our company, most commits on main currently have 3-5 authors (we squash): 1-2 humans, 1-3 agents (cursor cloud agent getting started, ppl pulling it into cursor locally to continue, then review using copilot review, modify using copilot agent) then use a vibe coded github app offloading UI test execution to a beefy baremetal machine to adjust baselines.
Copilot review in particular is just so good, better than any agent i know (incl opus 4.7). It just allows you to skip the first few review rounds by humans and fix simple but hard to spot logical bugs, keep docstring & style up to date across the codebase, before you give it to a human - which means everyone can focus on writing more code.
Setting all of this up, at a massive scale, is just not feasible for any of these projects.
You frame the symptom as the problem though. Others seem to be attributing this to Azure migration and Copilot overhead tightly coupled to GitHub infrastructure.
It's both and, it's a symptom of exponential usage and a problem with infrastructure. The question you aren't asking is "Why is it a problem with GitHub's infrastructure?" the answer to that lies somewhere in between: Microsoft + Azure + Copilot. Now tell me which of those have anything to do with GitHub as we know it?
Why is it a problem with Githubs infrastructure!? Bcs any website on the planet will struggle when they have to fulfill 30x capacity within 1-2y, no matter which tech stack they're built on, including federated networks. I'm not sure why you're throwikg Copilot in there, you don't like it?
Github as we know it is gone, forever, it will never come back, except for niche hobby clones with .001% capacity that nobody will use. Agents are re-defining what software engineering means, they already have, right now,and are continuikg to do so, it's just that hackernews is lagging 6 months behind for some reason.
I guess you’re right, in part I’m attributing the growth to Copilot and over prioritization of it alongside the AI feature factory galore and that’s where I’m coming from, but thinking again a lot of the acceleration of normal usage comes from AI usage through other vendors ending up in GitHub too.
I don’t know their internals, though clearly they choose to tightly couple every major GitHub system to the AI offering, in my eyes that seems like part of the problem (plus Azure cloud migration on top because Microsoft sounds like a disaster).
Not with you, just a little frustrated with the general vibe and tone in hackernews :) Nad it's not anyone's fault either everyone is just doing their best to follow what's happening. But I think hackernews is currently way off base when it comes to what's really happening, which is kinda sad considering it use to be "the place" to see what's currently going on. The AI revolution is here, anyone that's cussing about claude code max for 100/month getting rate limited doesn't understand it's already with 2k/month, everyone who's upset that github is focussing on copilot doesn't understand that this is the single modt important product they have to jump on asap or geit their lunch eaten by base44, cursor, linear etc.
I like to talk trash about Microsoft as much as anyone, they made insanely bad product descisions in the past (copilot in ms word is one of many) but this is not one of them.
Slight tangent: the post says that github is crumbling. Can someone get me up to date on what's going on please? Admittedly I'm not following tech drama particularly closely, but I thought I'd have heard if a major thing like github was going down the chute.
So there has been increasing issues form the github side for the past year and I believe they also just lost alot of customer/user data on top of several critical vulnribilities and bugs in base service and in actions.
My POV: Github actions are inconsistent in billing, security and require alot of attention to do right. Github has worse uptime than alot of free online videogame services, when most enterprise and business world leans on it for developers. Leaving a lot of users with terrible experience the past year having to constantly examine github firefighting for issues around availability, security, and billing instead of doing work that makes the company/people money.
Example walk through of securing github actions for ci/cd and managing SBOM python dependancy/supply chains (giant complexity) [1], Github has remote code execution[2], Uptime by 3rd party tracker shows 86% past 90 days. (First quarter in 2 years where they didn't have atleast one month above 90% uptime) [3]
> but I thought I'd have heard if a major thing like github was going down the chute.
Wow, it was a really long time ago it started going down the lane of the chute, can't believe someone missed it, made big news at the time back in 2018! This was the turning point: https://news.ycombinator.com/item?id=17221527
A federation of forges makes no sense if everything gets centralized again in the hands of the people operating Tangled (sure, someone else could run an alternative AppView, but then if you are only on the alternative you are invisible to anyone who is only on Tangled).
I'm sorry but I will never use this. I don't want a federated protocol and I absolutely do not want "social". The Git protocol is enough to distribute my source code to any Git server, so that part is complete. What I need, in addition and separate from Git, is a standard API schema for all the other SDLC bits: CI/CD, PRs, Issues, Packages, Containers, Branch Protection, etc. The API should not be a specific transport implementation, like HTTP, or AT. It should merely describe the schema, and then you implement that schema on anything else.
"createIssue(title=string, body=string, labels=[string])" would be the same in Git's source code as it would be on a REST API server. The point of this is to standardize the software development lifecycle everyone uses around Git. That way you can do all the work we all need, with any VCS, without tight coupling. That's been the missing piece that nobody has made yet.
Want just the CI/CD component? Use that part of the schema. Want just the Issues? Use that part of the schema. Now you can write any tool you want, and just implement the features you want, and say "this follows the SDLC v1 CICD standard", or "the follows the SDLC v1 Issues standard". Much simpler to add extensions or support different use cases, without implementing everything you don't need. Yet everything's compatible.
We need that implementation-agnostic standard, so we can make transport-agnostic protocols, so different providers, clients, and servers can all talk to each other, without a hundred different bespoke "things". Rather than write your plugin-downloading app only against GitHub or against Federated-Whatever, you write it to use "httpSLDCs://some-server/v1". Don't want to use https? Use "grpcSDLC://some-server/v1", or "atSLDC://some-server/v1". You layer the application-specific protocol on top of the transport protocol, and express that in a URL. That's how we did 'federation' in the 80's/90's/2000's.
(also: did nobody come up with a better name? Tangled? Knot? you want your solution to be a tangled knot?!)
People tend to focus a bit to much on the Git part of Github. Git is already relatively fine. It's nice to have a web view into the repo, users can just clone the repo, but many seems hesitant to do so as if it's some major operation (it can be for large repos, but normally it's not).
The tricky part is the bugtracker and pull-requests. I don't really know how I feel about the Github issue tracker. In theory it's a good way for a community to report and manage bugs, but it's also what's driving maintainers crazy. Previously, in the olden days, you'd send an email to a mailing list and maybe get a reply, maybe got told to show up with a patch or bugger off.
To some extend Github removed to much friction, and while quick drive by patches can be great, they don't build much community.
Personally, I prefer mailing lists. The tooling is there, it's consistent, and it's powerful. And if it adds a higher bar of entry, in this day and age that seems like a plus to me.
Please don't give your users a nickname like "tanglers", groups come up with their own nicknames. It's not as infuriating as when New Relic started calling everyone "Data Nerd", which is actually offensive to me and weirdly aggressive for a corporate product.
You completely missed the point.
The point isn't that you should find a company that you trust and think is ethical. The point is to shift the power dynamics so you don't have to trust anyone.
That's what building on ATproto does. Tangled is also fully open source and anyone can host their own knot and AppView.
I don't have a vote on whether ATProto is a good foundation to build such a thing, it seems to me rather that git has quite a bit of relevant machinery inside already, and maybe it might be extended a little, if only by convention.
but your overall point is extremely valid. lurching from garden to garden is just stupid for something so critical and core to the way software is developed. there should be a meaningful core standard for the data (the commits, PRs, workflows, etc). If people want to innovate and change on top of that great.
that's how GitHub started, but they flattered and turned the screws and convinced everyone that using them was the only viable workflow. for that matter can't we revisit the notion of a 'forge', that's really some product marketers version of how things should work and be bundled and charged for, not anything fundamental.
> Look how well that has turned out even though Bluesky is open source.
??? Bluesky can make decisions, mistakes, or moderation choices you disagree with and you can just go to https://blacksky.community, a completely independent AppView with different moderation that was up for the entirety of a 24hr outage Bluesky recently had.
Swapping one broken chair for another broken chair won’t cut it.
Development and steering is subsidised by VCs funding Bluesky at this point. (especially a crypto VC)
Have you ever asked whats in it for them?
What plans are they going to put into the protocol?
I can see the AT Protocol shoving crypto payments or whatever in their insatiable quest for growth and ROI, because when the funding money runs out when BS miss their growth targets, this is what happens.
And for Tangled’s monetisation path, it is questionable.
I only use GitHub for unified login git access to a bunch of repos. These other “forges” (didn’t know that was the term - cool) are all almost certain to put Anubis in front and make a logged out user be unable to access the code. I get why, but it seems inevitable. I think Codeberg already does and for some reason it takes ages to complete the challenge on my phone.
Undoubtedly these various hosts will come under pressure from spammers and the like and they will react by placing extraordinary barriers around accessing the code.
That’s fine but it reminds me of the later stages of online forums, where it was impossible to browse most threads because you had to create an account and then build up community points until the screenshot of the kernel panic on the ZTE phone would be visible so you could see if it’s the same problem as yours.
GitHub was big and powerful enough to not need all of this but now we’re going back to the era of decentralization and I suppose with that come the pros and cons.
reminder for anybody who might be interested: tangled is built on ATProto and when the bsky devs went public in saying "fuck the users", one of the tangled co-founders chimed in right along side them.
it's one thing to use the protocol of libertarian dickheads in the hopes of extracting it from them, but when it's done by other libertarian dickheads, there's not much chance of that outcome.
on balance, though, the tech appears solid. as in, it does what they claim it does and that is mostly what devs seem to need. if you're not interested in who you're giving your content to, at least tangled has the functionality that they're offering your content in exchange for it.
definitely in favor of git federation, and while I would prefer that it happens using git and only git, rather than another protocol on top of it, I get the feeling that there are at least some things that git wouldn't handle well that people would still really want, so I can understand why so many would reach for a wrapper protocol instead.
RESPONSE EDIT (clear and intentional rate-limit evasion):
hayden_dev: not going to dig up the specific source, but you can search for "bluesky" and "waffles" to find the offending skeets (or the dramatic thinkpieces about them), and you can read the responses to those skeets yourself, where you can find the tangled dev/cofounder.
psionides: hey, to each their own! I'd never ask you to call anyone a libertarian dickhead. and I'd also never begrudge your your opinion of someone you've personally exchanged comments with, even if I didn't agree with that opinion based on the comments I had exchanged with them. you do you, friend!
to anyone else that thinks they are... uh... "exposing" me... ? let me be clear in my bias: fuck the AT protocol - not because it's bad, because the people who made it are dickheads that are more interested in pretending they're building the future than in actually delivering a social product for human beings. They're not unique in this; in fact they are in very common company. most silicon valley types, especially those borne out of the largest social media companies in the world, prefer to make 'perfect systems', rather than actually engage with the imperfection of human social dynamics. but, to be clear, my condemnation for them is not unique to them either. I consider the heads of facebook, and google, and adobe, and microsoft, and pretty much any other large software company dickheads, too.
just because everyone sucks doesn't mean I'm wrong to say they suck. nor does it make me wrong to specify that THIS ONE sucks, without necessarily caveating that with "and all the others suck too, and maybe less". my problem is the seemingly endless loop of tech bros saying "well, it's the best we got, and they seem fine, so we'll make do with what they're giving us", and then eventually those same tech bros shrugging their shoulders when the whole thing falls apart because of libertarian dickheads and their priorities. We're at the start of the loop with ATProto, but for a look at the end of the loop, see the consensus on github today.
the actual "fuck the users" moment is described here [4,3095771], wherein a group of activists failed to get a person (Jesse Singal) they deemed unpalatable deplatformed from Bluesky, mostly by claiming that this person broke the ToS, and the Bluesky moderators mocked the activists in public.
nah, I'm you're run-of-the mill dickhead, I'm afraid. righteous and principled but ignorant and overbearing. classic asshole, by nature. doing my best to be better every day, though. hoping the same for everyone else.
as far as who isn't, the first names that come to mind are Fred Rogers - he seems like kind of the summit of what a soul can aspire to be. Randall Munroe seems like a pretty awesome guy. Haven't looked too much into him, though. most names that come to mind are personal acquaintances that wouldn't mean much to you, but I find that it's not very difficult to find non-dickheads in my day to day life. probably around 30% of the people I encounter in passing are a-okay in my book! but it is true that the number of dickheads I encounter skyrocket when I start approaching cultures that glorify personal gain over community success and health. abstract or practical; the business community is rife with awful people and los angelos is terrible for entirely different reasons.
anyway, yeah. I make a living. dealing with wonderful people who have a shred of humility and who - when they get called out - just sheepishly say "oh! wow, that is awful. I'm so sorry for saying/doing that." and everybody moves on with their business. I hope you work with wonderful people as well!
Today, not so much. But once the day is here where we have CRQC, if ATProto hasn't yet started using post-quantum cryptography for identities, users are either vulnerable or a bunch of stuff will break once they push a hotfix to make users not vulnerable.
Alternatively, they fix these things now, so once CRQC arrives, it's already not a problem, and no gets compromised nor have to urgently update their software.
I'm not sure it says much, but I met the person who wrote the post you linked to at ATmosphere this year. To me that says that maybe they're not as worried as you about ATProto's PQ exposure. I overheard lots of discussions about the topic, but I'm not an expert so I can't give much more insight than that.
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 desirable for some reason.
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 correct side) on
- Relatively little actual work/productive discussion going on, since many users are there mostly for the politics / fediverse posturing than for actual work
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 you can run your own hosting for your own data (if you want), and anyone can build an app that aggregates from everyone’s data (Tangled is one such app).
If this got you curious, I have two longreads: https://overreacted.io/open-social/ (conceptual) and https://overreacted.io/a-social-filesystem/ (diving into the data model).
> 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>
Atom is pull, Atproto is push.
Atom was designed for news, before social media existed, where 15+ minute polling times were (borderline) acceptable. Atproto was designed for social media, in an age of Twitter users getting their news in seconds, to the point of being able to comment on live events play-by-play. There's no coming back from that world.
With that said, I wish both Mastodon and Atproto supported opt-in pull-based, static sources.
> Atproto was designed for social media, in an age of Twitter users getting their news in seconds, to the point of being able to comment on live events play-by-play.
And this is widely recognized by now to have been a very bad thing, even/especially those most susceptible to its draw. It's strange that you're framing it as a strength and not a lament.
> There's no coming back from that world.
You can't say that when everyone just begs the question and shoves application-server-needed-here protocol designs to the fore.
> And this is widely recognized by now to have been a very bad thing
It has upsides and downsides. The ability to live-post an event, or get up-to-the-minute news, can be a good thing.
Because this is about synchronizing code and not realtime social media? Social media is just an example application of the technology.
There's always some Gemini protocol faction that shows up to yell that everything is wrong and we have to keep hand assembling our packets by hand or it'll never work.
Atproto's PDS is the root idea that everything extends off of, is the "social filesystem" that you control. There's a protocol objective to be able to spread your data around widely and for folks to be able to cryptographically check that that data came from you (even if you have to change hosts or even if someone sneakernets your data around). That's going to have some complexity! But it allows aggregation, is essential to how we are able to syndicate data so widely in atproto. It's so important it's in the name: Authenticated Transfer protocol.
And that in turn enables systems like Tangled here to be built, that layer stop the personal data servers, and relays. These work because there is identity.
If you need your static site to be on atproto (yay!), you can just have one of the various PDS hosts (such as Bluesky or eurosky or black sky or npmx) host the PDS for your. Since it is authenticated and user sovereign, you can permissionlessly move to a different host whenever you please, should that go awry. It's unclear to me why static site needs are an interesting or useful target that social networking ought conform to.
If you want to make a simpler network where we don't have those guarantees, please go right ahead. It feels to me like a snap reaction though that doesn't bother weighing what we have gotten or why things are this way, that is reflexively demanding.
> If you need your static site to be on atproto (yay!), you can just have one of the various PDS hosts (such as Bluesky or eurosky or black sky or npmx) host the PDS for your. Since it is authenticated and user sovereign, you can permissionlessly move to a different host whenever you please, should that go awry.
These seems to defeat the purpose of the relative amount of sovereignty that hosting a static site gives you compared to depending on a PDS.
> It's unclear to me why static site needs are an interesting or useful target that social networking ought conform to.
How is this possible?
Your data is still signed by you, and you still have the keys to move your PDS no matter what happens to your host. Do you have an actual threat model or reason why you are so afraid / unwilling to accept any compromise?
Your lack of a reply at the end, refusing to support basically your entire ask with even a modicum of supporting cause, feels a bit vindicating, that indeed you are a hostile agent & not here to engage or discuss, but to throw bombs.
> Do you have an actual threat model or reason why you are so afraid / unwilling to accept any compromise?
Have we met?
I host my PDS on a server from Racknerd that costs me $15/year
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.
Yes, all of those things are possible. Now imagine a protocol built from the ground up for those purposes, not just possible, but the entire community and ecosystem embracing those things.
you mean http?
We've tried that, multiple times. Semantic Web, "everyone has an API" and more before and after, none of them gain sufficient traction to stick around and be built on top of.
> Anyone can build an app that aggregates from everyone's data.
Unless they gut or disable their API, and then ban scrapers, although I understand why after seeing bots crush sites.
Who are “they” here? Hosting providers? Hosting is app-agnostic and you can run it yourself.
Thanks, that does seem better for this use case!
ATproto federates in a very different way than Mastodon. There is no concept of "instances" on ATproto.
Your account is hosted on a PDS and you sign into the app with your PDS sign-in and records go to your PDS, but everything on the app is from what's called an "AppView" which provides a centralized view of all data in all PDSes so it feels just like you're using a regular centralized app. But there can be multiple AppViews and AppViews can be self-hosted.
So unlike with Mastodon, it doesn't matter what PDS "instance" you're on because the app layer is completely separate from it.
> There is no concept of "instances" on ATproto.
Regardless of name and precise technical details, there are central service components that can ban you. If a proper ecosystem of those ever springs up then the equivalent of fediblock (ie guilt by association) oriented at individual accounts or PDS is the next logical step. At present (last I checked) there's only (approximately) one primary provider plus blacksky making the situation even worse.
This isn't some wild hypothetical - we also see guilt by association in the matrix ecosystem.
Details matter. Technical details matter.
Most bans today are at the "appview" level: the big indexed view of all the data, that combines the firehoses ("relays") marks accounts as banned & doesn't show their stuff. But the relay and the PDS still work.
Agreed that there aren't many public appviews for Bluesky posting right now, really just the two. Tangled itself though is an appview, of a different sort: one not for posting but for git issues/pr's/rtc. This appview isnt gated on Bluesky or Blacksky's permission. And folks could pretty comfortably host Tangled aplview themselves, subscribing their Tangled instance to any of the dozens of firehose/relay instances, getting all pre-filtered Tangled activity. And that really is quite decentralized a model that is imminently doable. Regarding the technical properly, the concern here about banning feels premature & naive: it assumes Tangled depends on these appviews at all, and it doesn't.
I will note that Phil's constellation project just tackles the key reverse indexing that comprises much of the appview work: taking all the firehose records, and connecting all the threads and likes together. Constellation runs ok as a public service on an rpi. There's a lot of challenges to making new appviews, but it is astounding and comforting seeing the core indexing for a sizable multi-media social network running on an rpi. What seems like a dire situation may actually be opportunity, if folks actually tried.
Whatever problems we want to foresee dooming us, whatever slopes we want to hypothesize sliding down, what we have here sounds way way better than anything else available to me today. Personally I'm much more bright blue sky sunnier about the prospects rather than your dark raincloud doom fall scare-away. The risk imo is immensely more weighted in not trying more than trying.
I'm not saying people shouldn't build things, merely disputing the idea that the logical equivalent of instances (and the ills they lead to) don't exist on ATProto. Guilt by association currently exists as a fairly common practice on all the community protocols I've made use of - including federated, p2p, and whatever else - so I see no reason to expect it won't also infect ATProto.
The key difference is that ATProto currently only has a small handful of instances, ie it remains largely centralized. Certainly it's a blessing that the operators appear to have generally acted with benevolence to date but that's not really relevant to the point I'm making.
Don’t they already have extensive block lists that you can “subscribe” to? I think some official blue sky account was added to some and they got super mad?
That's an additional (but closely related) issue. AFAIK those lists work at the user level to filter what you see, so while they aren't a network breaking "guilt by association" practice they're a form of centralized, lazy, delegated moderation that has outsized impacts on any borderline cases or false positives.
Besides those appview block lists, relays also block stuff. I know relays block stuff because bluesky isn't being sued for distributing child pornography, as it would be if it didn't block stuff.
To be fair, Mastodon is actually surviving.
Comparing open source social to algorithmically based social is never going to work, that's like saying the Light Phone isn't as popular as the iPhone, so its a failure.
The question is, does it work for you ? If over time open social gets a toehold then it will be an option people know about and can choose.
Not in expert in either but ATProto services (what they call AppViews) are substantially different from the fediverse because they rely on a shared relay instead of explicit federation.
I'm conflicted about the costs of what is currently effectively global discovery, but it's not just another Mastodon.
E: I think its funny multiple other people said the same thing in the time it took me to write this
Note a relay is a perf optimization and doesn’t have to be a single shared chokepoint.
These days running a relay is fairly cheap (~$30/mo?), there’s maybe a dozen of them, and some apps don’t use one at all (instead relying on services like https://constellation.microcosm.blue/ for querying backlinks).
As well as a confusing onboarding where users have to pick an instance, something both incredibly important, but with very little info to base your decision on. Pick the wrong one and your project gets screwed when the random anonymous instance owner decides to shut it down or go on a power trip.
Resulting in everyone just picking the "default" instance.
>Pick the wrong one and your project gets screwed when the random anonymous instance owner decides to shut it down or go on a power trip.
You say this as if it happens often, but it's more likely that a smaller instance will go under because of costs, and there are tons of perfectly fine instances where this doesn't happen at all.
Also you can join more than one instance.
Also it costs very little to host your own instance.
This is not a problem that exists for most people using Mastodon.
I agree the onboarding process is a bit confusing but really it isn't much more confusing than subscribing to a subreddit, except your identity only exists on that subreddit rather than a separate account.
Which I would definitely agree is a flaw but not an insurmountable obstacle.
How is any of this a bad thing? Isn’t the whole point to be able to do whatever you want in your corner of the federation?
Also, tangled is atproto based, the big blue mothership will always be in control.
You overexaggerate, but even so, that would be a huge step up (even if imperfect) from bring dependant on GitHub and GitLab for you to be relevant.
> - 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 correct side) on
Why do you have to take a side / take the correct side? Can't you either just not take any side or take whatever side you feel like and go with that?
On Mastodon, if you take the wrong side, those on the correct side will defederate from you. Not merely because you host (or don't host) the content they like (or dislike), but because you merely enable (or discriminate against) those who host that content.
Of course, all sides are wrong in somebody's eyes; so no matter what you do, you will be defederated from by at least somebody.
The way Mastodon works, defederation irreversibly breaks all follow relationships, without notifying those involved. If you disagree with the decision, you can migrate to another server, but you won't get your followers / followees back, not without everybody involved doing a lot of manual drudge work. This is just one way in which the myth of "users are free to do what they wish, if they disagree with the admins, they can migrate somewhere else" breaks.
To make matters worse, there's no way to see which users that you may wish to follow are / will be hidden from you if you choose a given instance. Defederation lists are a (somewhat open) secret; it's good practice to announce defederations, but there's no automated API endpoint to see them, so there's no way to answer the question of "who am I going to lose if I migrate from x to y."
> On Mastodon, if you take the wrong side, those on the correct side will defederate from you. Not merely because you host (or don't host) the content they like (or dislike), but because you merely enable (or discriminate against) those who host that content.
Ok, so? People block you all the time because they don't agree with you, why is that a problem? If people don't want to hear what you say, shouldn't they be allowed to not listen?
Personally, I don't understand that point of view of blocking people who you disagree with, for me the point of the internet is to find different views and perspectives, but I'm also fine with others filtering out whatever I say, doesn't really impact me either way.
If you want no rules what you say, run your own instance. Depending on what you say, some people will want to listen, others will want to filter your opinion away, I don't think either sides are "wrong" for that, it's just like in real life. If you want to use someone else's instance, you follow their rules. It mostly isn't harder than this.
No, because this happens on a per-admin level, not on a per-user level.
You go on a cruise for two weeks and there's a disagreement about whether to federate with Meta or not. Your admin takes a side, whatever that side might be. Two weeks later, you come back and lose 10% of followers, and there's nothing you can do about it.
Yeah, that kind of makes sense to me, you chose that instance because you're OK with that admin making choices for you. Just like how I choose to post comments on HN, and if the admins/moderators tell me to stop something, or that now half my comments are gone for reason X, I can't really cry about it, all I can do is follow what admins do/say or jump ship.
> you chose that instance because you're OK with that admin making choices for you
Nobody chooses instances for that, very few know anything about the admin, people just like the content until... in >70% of cases, bait and switch follows
That's why Mastodon is such an incredible mess, it creates the conditions for serious problems, then goes: "you chose what you knew nothing about, nor there's any way to know anything, therefore... you are the problem".
Yes, if you willing participate in an ecosystem where you know large swaths will be actively against you and try to defederate with you, that's kind of on you. Don't participate in that ecosystem if you don't like it, the ones already inside this ecosystem (like not me), seems to be OK with it and others outside of it (like me) seem to be OK with them having their own ecosystem where they can do these things.
Maybe I'm lucky in the instance I chose or the content I like being uncontroversial, but this isn't my experience at all.
I've heard of instances carrying a lot of Nazi content being banned, and of instances choosing not to re-host adult media (which makes the interface a bit worse, but doesn't actually block you from getting that). But most admins from what I've seen are pretty clear on this in the about page of the instance.
70% seems like a wild claim.
I have had content I like being removed from major social media platforms, like reddit and tumblr.
Also, if you choose an instance and it gets shut down, you just start another account. This isn't serious business, it's social media. To me, complaining about having to choose an instance to start is like complaining about having to choose a class at the start of an RPG.
Personally, I really love mastodon as a platform and I don't understand all the hate it gets here.
So... basically the bad problem everybody was intending to solve in the first place?
As far as I know, Mastodon didn't really set out to solve that particular problem. But it does seem like ATProto did, as it seems a lot easier to move around in ATProto than Mastodon (and ActivityPub in general).
Yep. Changing servers is easy. You just have to update the central PLC registry run by Blue Sky LLC to say which server you're hosted on now.
... wait a minute.
You're complaining that moving away from a PDS means you have to let that PDS know you're moving away? Do you understand what you're actually complaining about, or I the one who misunderstand what you're complaining about?
In case you haven't read them before, the docs for migrating are here: https://atproto.com/guides/account-migration
> there's no way to answer the question of "who am I going to lose if I migrate from x to y."
Ahckchually, once you create an account you can use the API endpoint for remote lookup to test in an automated manner which nodes are and aren't reachable.
They'll then defederate also from you. The argument goes, you're a nazi/facist/racist/*phobe, because you associate with (== did not defederate from) the designated nazi/facist/racist/*phobe.
Yes, it's that toxic. Go subscribe #FediBlock hashtag if you don't believe me.
Ok, so what? Let those people block you then, sounds like people you probably don't want to interact with anyways?
I've seen that, and I'm not sure what's supposed to be toxic. It's community-organized filtering of unwanted views, for the people who want to engage in that. I don't agree with that, so I don't participate or do that myself, and I also don't seem to face any negative consequences because I'm not participating in that. What am I supposed to be sad about here, that some people don't want to listen to my views?
Witch hunts and guilt by association are generally seen as toxic. If you disagree with that I'm not really sure what to say as it's a rather fundamental principle from my perspective.
> sounds like people you probably don't want to interact with anyways?
That's all well and good when it's a single user instance or small group of friends. But often enough it will be a much larger one with unknowing participants caught up in it. Blaming them for choosing the "wrong" instance is about as productive as blaming people for using facebook - technically correct but that's about it.
That said, the AP model seems like the least worst to me. Every option I'm aware of has significant downsides.
>Ok, so what? Let those people block you then, sounds like people you probably don't want to interact with anyways?
The problem is when this is a large server with people you know using it. They suddenly disappear from your feed. And those people may not have even agreed with the reason for defederation.
At that point, the only way to connect with your friend(s) is for you or them to find new servers that haven't (yet) gotten into a defederation slap fight.
The TL;DR of the problem with Mastodon is that you basically need to pin your identity to what is essentially a small internet community/forum and then give them full power to decide who/what you can consume while your identity is tagged to their community.
Look, life is complicated and not a single issue, contrary to what admins of many of those fedi instances would like. Typical human has views on multiple subjects, but it takes only a single incorrect opinion expressed to have you ejected. Worse yet, it happens by leveraging the admin of your instance: they go to the admin and tell him/her that if you're not banned, they'll defederate the whole instance. IOW they're bullies, and bullies squared at that: they designed a whole protocol to enable bullying.
Again, go check #FediBlock. If you'd like a specific example of the single issue vs multiple issues, pay specific attention to trans vs black conflict there and see how it is played by both sides.
I'd like to preface I'm pretty active in atprotocol ecosystem, so my experience is more than likely a bit more biased, but thought I'd share some of my thoughts as a big fan of tangled.
I've really enjoyed Tangled. It has so far been what I've wanted from a GitHub replacement, is simpler and does not have as many features, but it has been the main social/git provider I've been using for personal open source projects for about a year now (this me https://tangled.org/did:plc:rnpkyqnmsw4ipey6eotbdnnf)
- It has a social graph connected to it I know from the social media I use (Bluesky), it's nice to put a face/name I may have seen to their commits/prs/issues
- Is nice it's login is the same as other things I use
- They have recently added built in support for static sites, nice for those client side webites or simple index.htmls you want to host somewhere straight from your git repo.
- Spindles is their build system/actions. Not a nix fan, but they do use some flavor of that and have worked really well for what I've needed
- An open API that allows me to easily render information thanks to being built on shared standards I know (atproto). I've built bots and wrote a few features into npmx.dev that uses various things from tangled easily thanks to that.
- Ability to run your own knot(git server) and runner (spindles), or easily use the ones they host, but the cool thing about this is the social features are separate so even if you have a separate git server the issues/prs/etc are all coming from that shared social layer, not like they need to make an account on it to partake in the convo.
It's not perfect. It has alpha in the navbar and does feel like that sometimes. I am missing some features, but all in all I've really enjoyed using it for my open source work and will more than likely continue using it going forward.
I'm afraid that atproto will suffer from Bluesky's irrelevance. Not sure if that's a valid fear.
In what sense is bluesky irrelevant in this context? It's obviously not Twitter scale, but no alternative to GitHub will be GitHub scale for a long time to come either...
And it does seem to have the right feature set. Not sure which other social graph/network you could reasonably build a GitHub alternative around that would be less irrelevant....
It's largely perceived to be an ideological site. Obviously every community has its own biases and tastes, but I think Bluesky has just captured the imagination as the "left-leaning social platform." When the NYT was talking about a potential link between the WHCD shooter and Bluesky posts, that's what they referred to Bluesky as.
Obviously Tangled can live completely separate from Bluesky, it doesn't even need to share branding. Protocols are just protocols and people who don't understand how email works often don't even realize that Outlook and GMail use the same protocols. I'm hoping for this future personally where ATProto is only something the nerds care about (and write code for.)
(Please don't respond to this post with ideological argument. I'm just trying to talk about Bluesky and ATProto.)
>It's largely just become an ideological site.
That may be the case, but anyone can use ATProto. Unlike X where reach is suppressed for ideological motivations, or Mastodon with the federation turf wars, anyone can use it, regardless of their politics. If you disagree with the ideology of the majority users and avoid it for that reason, it just perpetuates the problem.
Unfortunately, I suspect it is only that way at present because the "other side" is perfectly content to continue existing in a communications environment that prioritizes them, rather than one that is actually open.
Unlike Mastodon? What's the difference? Anyone can use AP regardless of politics, you just might get banned from other's infra the same as for ATProto.
Fair enough! We are a pretty small ecosystem all in all. I will say in Tangled's case their infrastructure is separate from Bluesky's for the most part, and the rest can be switched easily enough if ever needed.
One example is if you don't care anything about atproto, you can create a new account on Tangled's website that creates the account on their servers, but thanks to how atproto works it's just like you made one on Bluesky and can still interact with Tangled and everyone on the protocol for it's social features.
We're not discussing social networks though, this is about Git project hosting. Bluesky doesn't have to compete with Twitter, Facebook, Instagram, TikTok or any of that for Tangled to be useful.
Everything is irrelevant until it isn't. Then it isn't until it is. If we all do our part, X will become irrelevant.
Aren't we reinventing what were forums in pre smartphone days?
Those were all isolated places, where you needed an account for that specific forum (whereas you can use your PDS anywhere), where that forum held your data (whereas you hold your atproto data, and we all internetwork to see the aggregate), where you were subject to the moderation decisions of that forum (whereas you have control over your PDS (but not other people's clients)).
Pretty unclear what your comment is trying to indicate but it sure feels very different to me, and I've offered some characterizations for why.
More generally, atproto is useful for all kinds of tech, solves a cold start social network problem. Aren't we reinventing forums, and tv watching, and book reviews, and trail maps, and photo sharing, and streaming, and d&d, and key attestation, and file sharing, and publishing, and note taking and containers and git hosting? Yes. Yes we are. https://atstore.fyi
(Under a common protocol set, in a way that respects users unlike everything else that's happened online so far.)
Isn't this stuff we're inventing more complicated than having accounts on websites?
atproto will suffer from centralization via Bluesky and its user wanting it to be centralized.
Lots of negativity in the comments and while I'm as distrusting of VC funding as the next guy I think competition in this space is something we should encourage, and bootstrapping that is hard if not impossible at this point. Obviously this post was timed well with the 2-3 GitHub-hating posts that made it to the top of HN yesterday, but I commend the attempt here. I hope it takes off in a meaningful way.
> Lots of negativity in the comments and while I'm as distrusting of VC funding as the next guy I think competition in this space is something we should encourage, and bootstrapping that is hard if not impossible at this point.
What you are calling "negativity" are genuine concerns to me. I was excited at the headline first. But as soon as I found it is VC-funded, it became a complete non-starter for me.
Look, I'm going to make my labor of love available to the world on your platform. I'm not going to earn a dime from it. It's just free work I'm gonna put out there. If I'm going to do that, I'll choose a platform where I can be reasonably sure that there won't be a rug pull 5 years down the line.
The problem with VC-funded projects is that there is definitely going to be some kind of rug-pull. Because the investors need their money.
The Git hosting services I use today are those where I can pay as a paying customer or I can pay as a paying member. As a paying customer, I know what I am getting into. As a paying member, I have the right to vote on decisions that affect the platform.
I agree with everything you wrote, but wanted to add to:
> The problem with VC-funded projects is that there is definitely going to be some kind of rug-pull. Because the investors need their money.
If you can tell me up front what the rug-pull will be in N years, then I could potentially look past it for certain use cases.
But if all you say is "I know you don't like VC-funded companies, but ours really is different because of X" then that's pretty much a slap in the face to users who've been through the hamster wheel of enshittification before.
The thing with VC-founded projects is that there's some kind of rug-pull, ads, privacy violation or "feature enhancing" subscription likely coming and as users we should know.
I don't really like services that stress how idealistic they are when this is the upcoming reality.
Better charge money for services or if you're truly idealistic start it as a non-profit. At the very least communicate what's the monetization plan.
The big question is (and I don't know the answer, so not rhetorical) whether the protocol being open can be sufficient to prevent the rug-pull from being too bad...
If their technology choices are holding them back it just means the product becomes more turbulent as they desperately thrash for a way to make more money.
A protocol isn't a good enough reason for investors not getting their payday. They'll just force aggressive and reckless changes to see a return.
The only way this kind of thing works is if profit isn't in the equation, or the easiest path to profit lines up with what's best for the customers.
This is why I'm skeptical about bluesky in general. Despite the protocol, it's incredibly centralised. If they wanted to make money it won't be long before they start putting up the walls around their garden. The same thing applied here as well, if investors demand a return the open protocol usage will shrink or become less open.
Bluesky proves it can't. So does every proprietary blockchain, e.g. Terra.
When did Bluesky rug-pull? Seemingly they seems hellbent on making it harder for themselves to rug-pull, at least judging by the developments of the protocols and ecosystem so far.
> and bootstrapping that is hard if not impossible at this point.
What points towards bootstraping being impossible? Sure, it's difficult, that's almost in the name so makes sense, but impossible? Especially if you're aiming for the federation-angle, then you should be able to build cheaper infrastructure, not the same/more expensive.
>What points towards bootstraping being impossible?
Even just the security concerns and having any confidence in the implementation is likely a specialized skill, so you'll need to convince someone to work for free or be able to pay them. Now do that for other major lines of work like UI/UX, Ops, and QA.
Take a look at all of the features from GitHub or any code platform that you'd need to get people to sign up these days (because they are used to GitHub/others) and it's a very tall list. Think something like https://www.enterpriseready.io/ but definitely larger (maybe 2x, 3x as large).
Oh and if someone writes a long rant about it and it gets to the top here, it likely becomes dead in the water, and you can't get the time back, making it a risky proposition. At least with VC money, you got paid a salary.
You could theorize about all those things, or you could look at Codeberg, sr.ht or others that already are doing what you claim to be impossible, yet haven't took on VC money. People are signing up and using these already, despite not offering 100% the same features.
The aim doesn't have to be "Be the next GitHub", but something else, and that's just as valid and "successful" as anything else, as long as they survive as communities.
My opinion is we need a new Github. It was fine for a decade, and can be again.
As long as it’s like Steam and stays private it’ll be fine.
If anyone here’s curious about atproto data model, I wrote an into here: https://overreacted.io/a-social-filesystem/
It’s a bit long but should give you a really crisp picture.
Understatement, probably. Your blog posts are so far the best introduction I've seen to ATProto. Is there any tagging I missed that collects them all in one place?
I’ve gathered a few here! (On an atproto social bookmarking site :) https://semble.so/profile/tynanpurdy.com/collections/3m5epi5...
Alas no, but it’s just a couple. I resisted adding tags so far…
just wanted to share how much i loved this blog post :)
Yes, excellent primer of atproto, nice one!
I don't think we need a federation of forges. What we need instead is just richer git repos.
Fossil gets 90% there with integrating tickets (issues), forums and wikis as part of the repo itself. When you clone a fossil repo, those are also part of the clone, and can be browsed offline on an airplane. Replies can also be written offline and, permissions willing, synced back up to the remote, either immediately or when the internet connection is regained.
I think this is the direction we should go in, but without hardcoding any specific artifact kind as part of the VCS. Instead, repos should be able to contain apps, which would define policies on what artifacts are acceptable, what rules they must follow, and who's allowed to upload and download them and at what times. The job of the forge would then be to execute those policies and render the artifacts for web users in whatever way the app desires.
With such a setup, moving to a different forge would entail nothing more than pushing the repo there.
Hey, so... Thanks for this. I've been building ticket systems and agents and whatever else as flat files in git repos lately and now I see I have to extend that to actually managing the repos themselves.
This is going to be so nice.
I think this idea is additive not contrary.
I still would like to be able to send and receive issues and pull-requests, to/from anyone.
Your idea here seems to be about how to encode the data. You talk about web interfaces & who is allowed to do what. But it's not clear to me how my repo/forge gets my PR in front of you. The social networking technology feels like it has to come into play somewhere, and I don't see that as described in your system.
The problem I feel with federated solutions is basically the 'cold start' problem.
When you are wanting to join a federated network, you have two choices: join a pre-existing server thereby creating the exact same problem you are escaping, ie: a giant server that holds you to its whims, BUT you do get a big network to begin with.
Or you start your own server but your network is zero, discoverability is zero, your feed is empty, and you have to convince other sites to federate with you / not block you for the crime of being a 1 person server / etc.
Am I alone in this feeling or am I just doing federation wrong? (But also this may just be a problem / quirk of Mastodon)
Yeah that's why Tangled didn't go with ActivityPub (Mastodon protocol) and went with ATproto instead, which is specifically built to solve that problem, so individual servers are all aggregated by centralized AppViews (that anyone can host) that give a singular unified "view" of the network that is just as cohesive as a centralized network feels.
Ah ok! Thanks for digging up info that I didn't go looking for myself. That's fantastic news.
ATProto simply ignores the need for decentralizing incentives on a human/community level. What we get is a sort of a "top-down" federation rather than a grass-roots one. Whoever invests in the infra ends up running a domain.
I mean, practically no one is aware of any other ATPROTO provider other than Bluesky whereas the issue with AP is merely the lack of better implementations, so mastodon.social got the most attention and the hype died off with niche success.
There’s no such thing as “running a domain” or “atproto provider” in atproto. You’re approaching it with a Mastodon/AP mindset and it doesn’t match that.
In atproto, there’s two axes.
One is hosting. Bluesky offers hosting but some people host on their own (it’s just a Docker container with sqlite), some on Cloudflare, some on community-hosted nodes like https://npmx.dev and https://selfhosted.social. From app perspective it looks exactly the same way (unlike in Mastodon where “hosting” = “choosing a community”) and you can switch hosting anytime.
Another axis is apps. Apps aggregate from data from all hosts. Bluesky is an app, Tangled is an app, Leaflet is an app, Wisp is an app, Semble is an app, and so on. Those can all aggregate over the same data (which enables cross-app interop) but they don’t have to (eg Bluesky doesn’t overlap with Tangled much except that Tangled can reuse Bluesky avatar on login). Generally you don’t have people running copies of the same app (as in Mastodon) which is why there aren’t many “blueskyes”. But when someone has an incentive, they can. (Eg Blacksky is a complete fork including server and DB, allowing their own moderation decisions over same data.) Similarly you can build your own app on top of distributed Tangled data.
Hope that helps clarify why “atproto provider” as a concept doesn’t make sense. You have hosting, which is as distributed as you want, and you have apps, which anyone can make.
So does Bluesky app have control over what data it aggregates and can decide (without checking with a user) not to aggregate data from a host? I am trying to understand what are the implications for a user, and a bad scenario where one would disagree with an action of the app.
And if the answer is "yes" then at least when someone "makes their own app" can they easily use "Bluesky hosts list" + add special extra hosts (or remove specific hosts) so that the app relies on the platform, with the exception the disagreement point?
Yes to both.
An app can choose to ignore/ban some users (or even entire hosting servers if they’re specifically created for network abuse). This is similar to how any web app may choose to ignore POST requests from spammers.
And yes, someone can decide to aggregate data themselves and provide an alternative app over same data with different moderation policies. In fact that’s already the case (Blacksky runs their own application server that mostly piggybacks on Bluesky moderation decisions but overrides some of them. There are also clients that ignore moderation altogether and show you the raw data from hosting.)
So the app is equivalent to an AP instance.
Not really. From my understanding, in AP, your account belongs to an instance and your data is then synced to other servers. If the instance goes down, your account is gone.
In ATP, your data is stored in the "Atmosphere", hosted on decentralized "Personal Data Servers" (PDS). The app then simply parses and filters that data. They can apply moderation actions by choosing not to display or read certain posts, but your data still exists and another app could choose to display it. Similarly, if the app goes down, your data is still perfectly intact in the Atmosphere.
It might then seem like the PDS is equivalent to an AP instance, but as mentioned, they are decentralized. Identity is verified through signatures, so if your PDS goes down, you can migrate to a new one as long as you have your signing keys. Therefore, the account belongs to you and not any specific server.
You're interpreting my post with the assumption that I don't know what I'm talking about. You don't need to explain the protocol to me.
Domain here referred to the area of influence or control, like what the provider of a relay effectively has. The fact that other groups can run any element of the infra themselves doesn't change the fact that the drift towards centralization is much greater with ATP than with AP.
ATP has its own uses (quick aggregation) but it doesn't even attempt to solve fundamental issues of current ecosystem of social networking,. AP, on the other hand, offers the foundation for further development in the right direction.
How does a new server discover other servers?
A new hosting provider can preemptively request known relays to crawl it. Or relays (or apps) can lazily discover it when the user hosted there tries to log in for the first time, or their data is linked to by a known user. It’s similar to the relationships between websites and search engines.
Hosting providers don’t need to discover other hosting providers. Data only flows between hosting and apps; not between hosting and hosting or apps and apps.
This is more a mastodon thing. atproto doesn't really work the same way where every server is it's own semi-isolating zone. This gets into it well: https://atproto.com/articles/atproto-for-distsys-engineers
I think the gain sits in the middle: if the giant server starts to get iffy (moderation, content, policy, technical issues), people can leave it somewhat easily and form or grow another decently sized server which will have enough reputation from day one.
We already have other decently sized GH alternatives such as Gitlab, Codeberg and various OSS forge instances (freedesktop, Fedora, Debian, etc) which could be federated and become a safe harbor if we were able to maintained project visibility and discoverability.
That's been entirely my own experience, or at least the assumption that's kept me off all of them so far.
But I saw this project a few days ago and thought to myself "Hey, this one could actually work." The difference here is that the target audience has a pretty strong overlap with the part of society comfortable with self hosting services.
I don't need my whole network for this one to be useful, only that subset that's actually most likely to show up.
I think the appeal here is you can either self-host or even migrate between larger providers.
The server costs for the frontend should be very low allowing them to operate basically forever and they are fed in by a series of other hosts
Not if you do it over git itself on the existing forge. You basically store everything in git and federate via git forks/mirrors.
For Mastodon, follow some tags through fedibuzz relay to populate your feed.
The CTO @pfrazee had a lovely New Year's Eve post that talks about Atmospheric Computing and specifically raising the cold start problem and addressing how atproto tackles it. https://www.pfrazee.com/blog/atmospheric-computing
Tangled here is a great example. An existing user base of a social network was able to rapidly join and start using a new app, a git forge, to share repos and collaborate. PRs and comments show up like any other record on the network.
As for how the network works: atproto tackles the cold start problem by layering architectural concerns. Each person is their own server ("personal data server" aka PDS). But aggregation layers ("relays") collect all PDS activity they can find and relay it to consumers. Then applications such as Bluesky or Tangled ("appviews") can be built by reading records of interest (of the right "lexicon" type) from the relays. Each person owns their data, relays make all data available, appviews distill out user experiences appropriate to the records they cover.
Tangled is VC sponsored. It doesn't scream stability to me, but rather "we need to grow at all cost". I don't see the appeal.
Even though it's federated, when development stops, who will be there to fix bugs and maintain it?
Tangled is built entirely in the open: https://tangled.org/tangled.org/core, and our primary goal is to be "permanent software"—i.e. be fully reproducible and entirely self-hostable at minimal cost.
VC money is a means to an end. We're both Indian founders in Europe, and grants are nigh on impossible to find (4–12+ months for anything to materialize). VC is quite simply the quickest way for us to build a team, setup infra and accelerate development. We're also incredibly aligned with our investors on our goals (we took 6+ months to find the perfect partner for this).
Hey! Love the idea. I think a lot of skepticism here would be addressed if you discussed your plans to monetize. People just want to know how you will (eventually) make money in a way that is aligned with how they expect this to evolve.
In the latest FOSS project I’m starting, I’m not avoiding all “open core” supposedly FOSS projects. In my experience, they’re the projects most likely to do a rug pull and change licenses. If they cannot commit to their entire project being free and open, they are less likely to actually be committed to the principles of free and open software.
While I was quite excited about some of the ideas being discussed in this project, it being VC backed is a complete non starter for me. Your claims of being built in the open don’t make me feel any better, you will eventually need to make returns for investors.
How can they ever see a dollar of profit without a rug pull, license change or hosted moat? This is a neat idea - besides just replacing github, a network of loosely-federated git servers seems like a promising base for distributed social media or chat platform someday - but it seems like the only way it can really stay open is if you're planning to stiff your investors.
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 themselves themselves are highly complicated, and the benefit of simple bootstrapping is easily overshadowed if the software itself isn't friendly to being extensively hacked on by the average programmer.
I've written about this: https://anirudh.fi/future
What does your investor expect as far as returns, and how are they going to get it?
I don't say you specifically have bad intentions or that VC money is all evil.
But now you need to grow fast, which greatly increases the risk for me as your potential user, so you should at the very least write a post to make sure you're aligned with your users not just with your angels.
How are you going to use the money? What's the business model? How do you ensure you're around in 10+ years? How are you going to please your overlords with that business model and what will you do if they force you to squeeze more money out of the business?
I hope you succeed, because the competition is good for users, but VC-founding is a liability not a strength.
Mmmm still rather not support this.
I prefer slow and steady wins the race kind of project. Good luck!
when in doubt, copy astral's exit strategy and get bought out by a foundation model lab. (yeah n=1, but that's still greater than 0 ;))
VC money is absolutely not a means to an end, what is signals is that the company doesn't care about community and only cares about profit.
I'm with the OP you're replying to. Taking VC is an albatross that means a large portion of devs will never trust you or use your services (outside of bleeding your funds dry).
If this place truly cared about community they should have made a non-profit or some type of NGO, basically anything with a true community governance model. Not the current model of caring about money over a community.
We currently live in a society that solely cares about money and seriously doubt devs want to continue uplifting the current system that only benefits the rich at the expense of everyone else.
How many board seats does the company plan on giving to the community to ensure enshittification doesn't occur?
This kind of absolutism is crazy. People who are doing 90% of what we want them to do should be greatly celebrated and rewarded. Else we penalize idealistic people who are not perfect instead of penalizing the people who are actually doing the opposite of what we care about (ex. Autodesk).
Do you want software to become as closed source as mechanical engineering? No! So let's celebrate people building software that's open source, even if it's VC funded! They are awesome for doing that!
This kind of absolutism is absolute necessary against tech leadership that are anti-democracy.
Two founders of a small startup in Europe trying to build a new decentralized git forge and open sourcing their code are anti-democracy?
Come on.
The problem with VC-founded projects is that there's some kind of rug-pull, ads, privacy violation (e.g. using repos to train AI) or "feature enhancing" subscription likely coming.
As a user who would need to invest time and effort in using Tangled, I think it's fair to ask to have the plan explained. I'd rather see explicit price for services than see enshittification happen.
Just like engineering, monetizing is an iterative process. As long as they don't make it hard to move off their platform, IMO it's completely fine for them to try different monetization models.
We should celebrate people building open source stuff and in the public. The alternative is for the software tooling ecosystem to look like EE or mechanical engineering tools - all closed source, proprietary, and with super expensive licensing.
It's easy to take open source for granted - 'information wants to be free', but we are at risk of the open source movement dying with proprietary AI completely changing everything about software.
If we penalize people who are working toward the right goal, we contribute to that decline.
You're badly missing reality here. There's no "community governance" as there would be in a local farm shop or something. It's a bunch of online people with interests. They aren't going to visit you if you're sick or coach your kid's team or attend your funeral.
The two reasons actual communities work in actual locations are: 1) because to some extent the people all live in a place and want the place to be nice for them and their (grand)children, so they are invested personally and 2) companies aren't set up to help communities. Communities are the ones doing community things. It's crazy to demand other people do work in a certain way when you're doing nothing.
> the company doesn't care about community and only cares about profit.
There are plenty of examples of VC funded companies that care about community & don't "only care about profit". Bluesky is a good one (literally a community / social platform). That's such a black & white take it baffles me.
> Taking VC is an albatross that means a large portion of devs will never trust you or use your services
A "large portion of devs" (the majority) use so many VC funded services? Probably _most_ services devs use are VC funded. GitHub itself - was VC funded.
You can have an anti-VC opinion but you have to also live in reality.
> Probably _most_ services devs use are VC funded. GitHub, was VC funded?
GitHub was founded in a very different world. Would we start using it today is the question.
O yeah cuz the non profit tactic worked so well for OpenAI.
OpenAI and Claude both took VC money and everyone on this message board uses them regardless of ~community~
Not all VCs are scum
It's not about VCs being scum but about investors needing a relatively fast return on investment which is understandable but also often times incompatible with investment in large scale, open source infrastructure.
Would you be open to sharing a version of your pitch deck? The main question in my mind is what kind of exit the VCs have in mind when they give you this money.
Is the code base AI slop? You've published your code as open source, but without an explicit AI policy.
> who will be there to fix bugs and maintain it?
Those of us who use it. Tangled is a neat project and architecturally it makes a lot of interesting choices but code-wise it's relatively simple and from my personal forays in it I'd say pretty easy to maintain.
The majority of the codebase is loosely related go modules. Then some static HTML+CSS. And finally a small sprinkle of typescript to tie things together. And of course a bit of Nix for orchestration.
IIRC it all runs on a pretty trivial amount of hardware that a single person could currently host by themself.
Users' knots, spindles, and PDS (plus atproto at large) do the real heavy lifting infra-wise.
The most valuable thing Tangled will ever do is establish the protocol of Tangled. Once that’s done, it lives as long as people are willing to run it.
Exactly. I'm personally slowly working on my own parallel "appview" of tangled that is accessible exclusively via SMTP, IMAP, JMAP, and eventually integration with a Lore + Patchwork frontend.
Oh that sounds very cool! Where can we follow your progress?
I don't think that will work. How many of us did contribute a simple patch to LibreOffice, Firefox, or GNOME?
At least this statement doesn't hold for LibreOffice. Their Online version, including "simple" HTML/CSS components, was archived because of a lack of maintainers. For their main project, the vast majority of contributions in the last release were made by former ecosystem partners (Collabora) or TDF staff. Volunteers only did a fraction of the work [1].
[1]: https://www.collaboraonline.com/wp-content/uploads/2026/02/L...
its one of the most complex htmx projects i have seen. super cool.
You wrote this comment on a VC funded news aggregation website, so who's to say?
This website is funded by providing brainwashing services for YC's agenda.
I don't mind VC funding as long as they aren't YC funded.
Why?
When a project is funded by these VCs I question:
Why does it need VCs? Why not company and corporate sponsorship like Ladybird?
Why should we spend our time on a developer tool that would be enshittified down the line when VCs expect 10x returns?
In this case the VC in question is funding various atproto projects as they are one of the primary backing VCs for Bluesky.
So even if they don't expect returns from a given atproto project, they are investing money (and therefore funding FTEs) in the ecosystem at large.
The investment isn't necessarily in any one of these projects in isolation. It's in the AT protocol at large.
> Why does it need VCs? Why not company and corporate sponsorship like Ladybird?
You talk about corporate sponsorship like that's trivial to find. Trust me when I say we spent over half a year chasing down grants/sponsorships only to be met with closed doors, extremely long wait times for pennies. We'd also be required to keep our day jobs—which means less focus on Tangled dev, and ultimately very slow progress overall.
We debated VC heavily (we're both idealists after all), but figured we can make it work—it's ultimately the founders that make bad calls leading to enshittification. There's plenty of examples of VC-backed companies that haven't enshittified. Tailscale is an excellent one, and hence we brought on Avery as an angel in our round.
Sure Tailscale is an excellent one. For now at least. It is also not open source and also has a paid product.
Perhaps maybe in a few years time, Tangled Enterprise would be available to compete with GitHub Enterprise and that is where the switch over happens for companies who want to move over from GitHub to Tangled.
I don’t know because somehow Tangled would need to make money somehow?
I hope Tangled becomes profitable enough to withstand enshittification, because more and more funding rounds and not meeting targets means giving up control and facing a repeat of what happened at Bluesky.
Forge federation seems like a bad idea to me. If you want to go the route of decentralized project management (note that git as a VCS tool is already decentralized for this purpose), you're probably much better off modernizing the git-over-email workflow instead.
Decentralizing the code isn't an issue; cloning repo's between servers is so standard that any forge can import a code repo from any other forge.
The difficulty is ancillary stuff like issue trackers, wikis and MRs, but using a federated protocol for that seems ill-advised given the much weaker safeguards against spam. Mailing lists have a very large existing body of work on the matter of dealing with spam and a proven method of mirroring/archival. (Most git wikis are just git repositories with a different renderer.)
The main reason nobody likes doing git-over-email is mostly just because it's very user-unfriendly to set up (since modern mail clients typically aren't correctly configured to deal with them). It's a very developer oriented workflow in the worst way possible. A modernized mailing list program that automatically takes care of things like reformatting emails/not leaking email addresses to the general public would go a long way to make it easier to deal with.
I had never done the PR-over-email thing until I got an account on SourceHut; it was a bit of a chore to set up, but not that hard, and it did make me feel like it's very clearly the "correct" way of doing things.
GitSocial solves this: https://gitsocial.org/
"There are 4 standards that try to solve this problem, its too many, we need one that finally unifies it all and solves the problem once and for all" "There are 5 standards that..."
Jokes aside, I think we need stronger arguments as to why something like activity pub is not good enough to solve the problem instead of trying to come up a new way of solving the "decentralized comms" problem.
ActivityPub and atproto are differently shaped. Pitting them against each other is like asking “why need web when we have email”.
ActivityPub is email-shaped. Servers are inboxes sending messages to each other.
atproto is web-shaped. User repositories host data (like personal sites or git/RSS), while apps aggregate from repositories (like Google Reader).
Different topologies lead to different properties. Eg atproto lets user change hosting with no disruption in app experience. atproto also lets anyone build new apps aggregating over existing data.
ActivityPub doesn’t allow either of those things. It’s literally a bunch of small centralized coupled hosting+app services messaging each other.
Calling AP services a bunch of small "centralized" services in this context removes all the meaning from that term. You might as well call any web server centralized while comparing them to clouds.
Proper federation is exactly such bunch of small services messaging each other. On the hand, what ATProto leads to is at most a handful of large-scale providers each running the own portion of the network.
There’s a clear difference in architecture between
1) a layer of app-agnostic hosting providers + a separate independent layer of apps aggregating over data from those (like personal sites with RSS + aggregators like Google Reader)
2) a circle of flat instances where each node couples app+hosting (like many little Twitters)
One doesn’t couple hosting with apps, another one does.
Mastodon/AP model is (2), atproto model is (1). You should be able to see the outcomes from different network shapes.
In atproto, you can build a new app that works with existing data, but in AP you can’t. In atproto you can move hosting with zero effect on your identity or how you show up in apps, in AP you can’t.
I dunno man. Why was Tangled able to ship on top of ATProto even prior to getting funded, and ForgeFed has been hanging out for years?
That's become my answer to all "why not ActivityPub?" questions.
AP isn't completely stagnant but there's a reason AT is still holding on to and accelerating that early developer excitement AP had. Maybe it's marketing, maybe it's money, maybe it's some technical thing. Maybe it's the community. Whatever it is, people seem to enjoy developing in the Atmosphere in a way I never saw on AP.
If you consider people's worries of centralization happening with AT, that's not necessarily a good sign.
Of course VC funding and startup mindsets prefer a protocol that is easier to rugpull.
its linked in the original post as well, but here is an explanation of why activitypub is not a good fit for this problem, by the authors of ForgeFed themselves: https://forgefed.org/blog/actor-programming/
Reading that - I'm really not sure that AT Protocol has a much better story there either.
(as I understand it) the data has to live in a PDS, PDS are keyed by accounts, so you are similarly stymied for collaborative projects? I guess AT Proto is still a real work in progress so maybe that story has improved since the last time I checked it out.
> But federated authorization is one of the things ActivityPub doesn't define, and leaves it to us to figure out.
this is the key bit, atproto has this. sidecar services like knot can use service authentication[0] for authenticated requests.
[0]: https://atproto.com/guides/auth
Yeah the problems they seemed to have were over collaborative data structures with permissions. You’re right about how atproto solves that, which means you’re using CRDTs if you need to collaborate. If that’s a fit mismatch, I’d tell people to just appoint api servers which wrap a repo and provide the needed semantics.
Yeah, capability for group permissions is a key part of the work happening on permissioned data in ATproto right now.
https://dholms.leaflet.pub/3meluqcwky22a
https://dholms.leaflet.pub/3mfrsbcn2gk2a
https://dholms.leaflet.pub/3mguviy6iks2a
https://dholms.leaflet.pub/3mhj6bcqats2o
Or email. AP is very similar to SMTP over HTTP.
Why? I really don't see the purpose of a federation of git repos. Git is already totally decentralized. 99% of projects only have a small list of committers. Tangled just doesn't solve an actual problem. Github was used because it was an easy to set up, free, place to store code and share it, and it had source viewing which was a step up from sourceforge. With multiple solutions available that makes this easy, its just not necessary to federate anything. The common user account part of github just isn't critical.
Discoverability. Without federation, people are pretty much dependant on GitHub to make sure their software gets out there.
How do you discover new software using GitHub? Let's say I want an RSS reader for Linux - how does GitHub help me find one? I must have never used this part of GitHub.
Github has search functionality and grouping of repos by topic, etc. So you can browse repos related to a specific topic. Or you can click on someone's profile and see the projects they've worked on and maybe one of them is interesting.
Github ranks higher on Google search.
There’s a lot more to GitHub than just the git part. Issues, PRs, etc.
Why does issues and prs need to be federated? I can't think of any part of Github that benefits from federation. Just set up your own instance.
They do if you want to collaborate with others. No one is going to want to create accounts on your personal instance
I think initiatives for forge federation are trying to do too much. When running a forge for a project, I'd don't want to be dealing with spam or large amounts of data from other instances. And people should be able to report bugs and upload attachments, without having to give permission to share those with other instances.
A good system to download and migrate issues and pull requests is important, but that doesn't require federation.
I would love to see a smaller scoped federation of:
Because we are headed into a world where attacks on project hosting are more common, and loss of issues/PRs can halt a project while setting up an alternative and attempting to restore archived information.
The attacks span from forged DMCA takedowns, to national blocking orders, to suspicion that a contributor is from a sanctioned country (whether they still live there or not), to rogue project admins, and some other more creative attacks.
Project infrastructure should be distributed, with copies of data in as many computers as possible, across as many jurisdictions as possible.
It's easier and enables more features to have 1 common platform.
For example, the social features of GitHub, which I like (like stars, browsing repositories by tags etc..)
But also For PRs, the way to make a pull request to a repo hosted at A, from your own node hosted at B.
And like other commenters said, you can do this workflow with git over email like a lot of projects to, but the main goal of the federation here to me is the user experience, the UI being able to link all of theses separate repositories, issues, PRs, etc, like everything was hosted at the same place.
One approach is to keep it all in git itself, the way GitSocial does: https://gitsocial.org/
I don't know how new Tangled is, but there is a fairly mature github alternative being built on Nostr:
https://gitworkshop.dev/
The basic idea is that you can put your repository on multiple GRASP-compatible nostr relays (GRASP is a sub-protocol that glues nostr and git together), so even if one server goes down you can transparently sync using the others. This means in effect 100% uptime if you choose reliable servers, as well as cryptographically-signed repositories, activity, issues, etc.
not that mature — its name violates git’s trademark policy
https://git-scm.com/about/trademark
This is a meaningless fact unless Git actually sues them for infringement. Failure to quickly sue can be seen as tacit approval.
Do github, gitea, and gitlab not?
i can't speak to gitea, but github and gitlab are explicitly mentioned as having a license in their policy:
> Please be aware that GitHub and GitLab are exceptions to this Policy because they are subject to explicit licensing arrangements that pre-date, and thus take precedence, over this Policy.
From gitea:
GIT is a trademark of Software Freedom Conservancy and our use of “gitea” is under license.
Correct me if I'm wrong but the project you're referring to appears to be closed source.
It's all open source, hosted on nostr itself. See the creator's profile for all related repos:
https://gitworkshop.dev/danconwaydev.com
i am unable to access any repository on that website. for some, it complains that ssh or https URLs are not supported by my browser? and for others its just loading indefinitely with `Failed to load file tree`. maybe its not fairly mature.
Sounds like a misconfigured repository. Try for example https://gitworkshop.dev/danconwaydev.com/relay.ngit.dev/ngit...
That one specifically fails catastrophically for me.
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 complexity of a "forge federation" system.
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 find software from any host – like ForgeFed would.
There’s also the concern with the friction created by requiring newbies to log-into a dedicated forge for contributions (which ForgeFed solves), but I reckon that’s a secondary and related concern.
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.
> If people want to find software, they search GitHub.
people really do that?
The only time I ever search GitHub is when I'm trying to debug or understand some esoteric API (usually Apple-specific) and I'm looking for anybody else who has actually used the god damned thing.
If I'm looking for software/libs/etc, GitHub search is the absolute last thing I would even think to look for.
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. Federation may solve it, by staying closer to the decentralized philosophy. That's my read.
Not sure I understand, you're talking about mirroring git repo data between multiple different nodes? That seems unrelated to what's proposed in the OP--maybe you're seeing something I'm not?
if I fork a repository to my forge, I expect my forge to have an independent copy of the repo
How does that fix "when one node goes offline you may not have any upstream to pull from"? You'd still have your own local copy—just like git—but you wouldn't be able to access any sense of "upstream"
By hosting a knot.
You may ask, well, that's like hosting forgejo or any other git server, where is the federation?
Tangled uses a protocol. So knots would adhere to that protocol allowing to pull from any upstream.
That's my understanding of federation. not saying tangled will go as far as figuring out discovery across their cloud hosted knots and self hosted infra. But that can be done, and claiming to be able to pulling from any repo with a single identy would imply just that.
The biggest problem IMO is discoverability. I need an easy way to find open source projects that are on scattered servers. GitHub project search is limited to GitHub.
The OP says that tangled only supports event federation. How does it help with discoverability?
Events in atproto speak are changes to metadata/records, i.e. repo/MST events on a PDS.
So for tangled that means federation of issues, PRs, comments, follows, stars, and anything defined in an atproto lexicon. i.e. everything except the actual git repo itself. Those repos are singularly hosted on a given knot for the time being.
Now it's not a huge leap to imagine extending functionality to support cross-knot mirrors but that's not a supported feature yet. And of course you can always just fork a repo instead.
Github is already in practice federated, within the confines of github. If you fork a project you now have your own federated git forge with that project.
The difference is that these same flows should work without needing to be github to github.
Interoperable identity providers would indeed be useful.
Beyond that, maybe resilience when a project's host disappears, changes its policies, or gets blocked by a government?
How does tangled solve that? Repository contents are still hosted by the forges themselves.
I was addressing the question of a use-case for a "federation of forges". Not any specific design or implementation.
That sounds more like you want better decentralization, like IPFS or BitTorrent, not necessarily federation between different forge instances. I'm not familiar with any existing federated system that would be resilient to government censorship. Certainly Mastodon and Bluesky aren't.
> I'm not familiar with any existing federated system that would be resilient to government censorship.
Usenet and Matrix are notable examples.
Usenet is, Matrix isn't. Usenet achieves this with a broadcast design - every node on the network receives every message. As a result of this and being flooded with half a petabyte of new messages per day, there are approximately 3 (three) nodes (all other providers are reselling access to one of these).
The text side of Usenet is healthier, with a few gigabytes per day, and not trying to retain every message forever. Would it work if it was also the world's git forge though?
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 personally I'd rather have a single account to manage -- and the AT protocol means that any individual forge can go down, but the data remains accessible from other AppViews.
In this case the PDS is only storing social data though, right? The forge would still store the repository data itself.
Aha, I was mistaken -- I was under the impression that repos were also stored on the PDS.
Looks like that's where knots come in -- you could replace "PDS" with "PDS and knot" in my earlier comment and it holds true, I believe.
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 already pull-based. We don't need another protocol to listen for changes at a URL. The web already has support for different content types and document schemas, we don't need to reimplement content types and schemas as ATProto "lexicons".
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.
You're right. RSS builds on top of the web. ATProto does not. I'd say RSS is a resource format / content type, not a communications protocol. A resource format intended for syndicating updates – exactly what ATProto and ActivityPub do (but decided to invent new formats instead of extending RSS/Atom. JSON all the things!).
It is very much about identity. To use tangled you need to use ATProto and authenticate using ATProto – rather than using the existing open standard for authentication used by pretty much everyone at this point (missed opportunity to login to Tangled using GitHub). What's crazy is people still use the web to interact with tangled anyway.
AT Protocol uses OAuth: https://atproto.com/specs/oauth
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.
A federation doesn't mean the forges talk to each other. It only means there's more than one, and data flows between them. This can occur by developers pushing and pulling from different remotes. You already have a different remote for each fork, you lose nothing if they're also on different servers. Communication about the project can also happen in many places.
It appears that git format-patch + git send-email is a mature and widely used approach. Wouldn’t it make more sense for the open source community to work on streamlining that process instead of trying to build momentum with new approaches?
For what it's worth, under the hood tangled is extremely similar to this approach.
Personally as just a random person in the community I've been building an appview for tangled that lets you interact with it as if you were just using git format-patch + git send-email + some MUA.
You can conceptually treat the tangled lexicon as a schema for encoding a git patchset based mailing list into IPLD/atproto records and vice versa. Doing this is slightly lossy but only barely. Otherwise it's pretty seamless.
Tangled is pretty cool. I'm not particularly into atproto, and I think the connection kind of distracts from the reality of what it is and can do.
You can host your git repo on their servers, or your own. You can host issues/pull requests/runners/etc on their servers, or your own. Regardless of where a repo is hosted, you can interact with it from a single account, and with that same account interact with others' repos connected to tangled. Plus it has native jujutsu support, though you can use plain ol' git if you want to, too.
Do I think a forge with those features necessarily needs to use atproto to exist, or that atproto is the ideal version of itself? No, not really. But the site is there, and it has some pretty neat features I want; I don't need to love the stack to use it, any more than I do Github's.
GitSocial allows cross-forge collaboration without any 3rd party dependencies as it keeps everything in git: <https://github.com/gitsocial-org/gitsocial/blob/main/documen...>
Git IS the federation layer in this case.
How do you authenticate the identity when people are submitting patches between two repositories running on two different servers?
There's a federated identity spec and implementation: https://github.com/gitsocial-org/gitsocial/blob/main/documen.... For GH/GL, just an api call to verify signature, for custom domains, it's .well-known/gitmsg-id.json
Forgejo also has a roadmap for federation but it looks like development is progressing rather slowly: https://codeberg.org/forgejo-contrib/federation/src/branch/m...
You will never get around the free rider problem.
If I want to create 100 repos of vibe coded projects every month someone will have to pay for it.
At this point, just give me an honest version of GitHub that tells me what things actually cost. 5$ a repo, and another 1 per gb stored in LFS, cool.
The cool thing is you can just host your own knot then. Host repos of whatever size you want.
Man I really want to like this thing but this jargon is so stupid.
The jargon is just naming the free-standing components after rope/string related things. i.e. tangle, knot, spindle, etc.
Just call them what they are. Federations/networks, servers, repositories...
You got pretty much none of the names right.
Tangle: the appview server of the tangled network.
Knot: the git server that holds an arbitrary quantity of git repos.
Spindle: CI servers/runners/nodes.
Each one is the name of a component and the name for those components is pretty arbitrary.
I think they're mad because 'knot' is a furry fetish term.
Pretty much every word in English seems to have an innuendo meaning to someone, do anyone truly care past the age of 15?
I find Tangled's language a bit annoying because I'm pretty sure if this caught on it's even more single word concept rather needlessly. If the protocol is called Knot, then call a server a Knot instance or Knot server. If the runner protocol is called Spindle, each server which responds to that could be a Spindle runner. That'll serve two functions: It'll let people contextually hook the terms up against existing terms and still retain the option of evolving into singular word concepts if they prove successful enough for that to happen.
From my point of view as a non-native speaker, the frequent overloading of commonplace words add to the confusion of learning English. I don't like that. It's far from a big hurdle, but just big enough to earn a soft little sigh from me.
Your comment was the only thing that made me even care to comment: Isn't it rather unlikely that the person you're commenting on takes issue with a kink rather than any other reason why "knot" and "spindle" might be poor choices? Who knows, they might even have a good reason, but you started out with assuming bad faith and at least I tend to just leave conversations at that point.
Similar UI but donation based and public repo only: codeberg.org
Fixed low cost but different UI: sourcehut.org
Source Hut looks cool, the website is confusing though. What build systems do I get for 4$ a month ?
Getting my friends to feel comfortable moving ( so they can view the UX ) too will be a challenge.
I like their build system, is very simple to use, based on shell scrips, and has some neat features, like ssh-ing into the machine that had a failed build, or spinning a build with a custom manifest file (useful when you need to iterate quickly).
Although it doesn't have all the "plugins" and other stuff that CI tools have today, it provides fairly "standard" points of integration
For more info: https://man.sr.ht/builds.sr.ht/
I agree the website is a bit confusing at first, but after spending a couple of hours on it you can easily see how it's organised, for example to display branches and files it uses the more basic git terminology (e.g. main branch -> tree, list of commits -> log, branches and tags -> refs)
Federated solutions seem to be the future, after once-beloved provider becomes the crumbling monopoly.
It's not a clear one-way trip though. The "original" blogosphere of the 2000s was heavily federated with MovableType supporting trackbacks and then later systems automating that further with pingbacks. Ultimately it all fell to spam and hosting complexity though, and now almost all blogs are on a handful of centralized hosts again.
Spam/moderation is going to be the biggest hurdle to overcome with any distributed forge effort. It'll likely come down to some kind of web-of-trust/vouching system, but it's delicate balancing ease of access with not making it a slog to constantly manage spam.
At least with atproto, we can see if an account has history and activity, see if their public data looks at all legit. The ability to deal with spam and disinformation seems so much radically better than anything else we've been able to work from.
Has it ever worked?
Mastodon, Discord?
Is Mastodon successful enough to be called "the future" of its niche? MAU is 1/3rd what it was at the peak, and bluesky + mastodon MAU combined is microscopic compared to twitter (I use none of these services, no dog in this fight, just looking at numbers).
Discord is not federated.
Twitter is full of bots, flamers, and scammers. I wouldn't trust their numbers.
Forgejo is working on federation powered by ActivityPub and their ForgeFed extension: https://forgefed.org
GitHub is a huge and almost 20 year old company suddenly experiencing massive scale growth as a result of an externality it didn't cause and that no one predicted. That is an incredibly difficult scenario for any long-running, established organization to handle.
Yes, GitHub is temporarily breaking under the increased load, yes, it's likely to still be a thing in 2 months, and no, it's unlikely to still be a thing in 12 months.
It's very unlikely a cool new thing will peel enough developers off GitHub in the next six months to survive long term as GitHub inevitably gets its ability to handle the new normal scale back.
tangled is a really cool project; the most important feature it provides is that it is jujutsu first.
I don't really see it.
I used JJ for a bit, but I personally really, really dislike the anonymous branch approach it forces you into.
Branches are just useful conceptually, at least to me. For the same reason I like my documents grouped into folders.
Frankly - I think JJ just ended up taking up far more mental bandwidth than git. Simple operations need generated ids, commands require complicated input (ex - the entire revset thing), I have to be constantly thinking about the tool and its structure.
It feels really oversold to me. It's solving problems for people who live in source control, not problems for people who just want snapshots of code every now and then. Hell - just look at some of the example commands from the suggested tutorial:
jj new ym z r yx m -m "merge: steve's branch"
jj log -r 'ancestors(trunk, 2)'
jj new o
jj log -r '@ | ancestors(remote_bookmarks().., 2) | trunk()'
---
With all due respect, if the intro tutorial to your tool includes a command having to literally write function names in quoted commands, or run a command with fucking 8 (EIGHT!) arguments... You've jumped the shark.
Not trying to harsh anyone's buzz - if you like it... great, it's clearly quite powerful. But it misses the mark for me. I want "just powerful enough" with minimal mental overhead.
If you cherry pick complicated commands, and remove all context, sure, they look cryptic.
I wrote that tutorial, and literally only one of those is relevant to my day to day work: jj new o, which means “make a new change on top of the change named o”. Yes, if you remove the context that “o” is on your screen and highlighted, it looks complex.
It’s the same with the other “jj new” command: you’re producing a merge by giving it every branch you want to merge together. If you’re merging five branches into one, you need to provide five identifiers for those branches. It could not be simpler than this. And -m adds a message, same as git.
The other two are showing off the power of the revset language; you’re not typing this stuff in yourself more than once, and if you are, you use an alias so that it’s shorter and easier to use.
> If you cherry pick complicated commands, and remove all context, sure, they look cryptic.
Sure I'm definitely not playing fair, but I am cherry picking from the intro tutorial you put together, so I'm not going crazy either :P
I think my primary issue is that jj feels like it wants to control how I work more than git does.
Mentally - I just don't want to have to think about changes as often as jj seems to want to think about them. And maybe it's an intro phase, or a thing you eventually build past (I only played with it for a week or two) - but it felt like a lot of focus went intro structuring my work, instead of doing my work.
Basically - the vibe I got from it was: if you're a person who really likes making checklists, or complex tickets with subtasks and groupings and labels - jj is something you're going to like. If you're just interested in writing code and not so interested in source control outside of the ability to occasionally "snapshot this folder"... it's probably not going to be your thing.
> The other two are showing off the power of the revset language; you’re not typing this stuff in yourself more than once, and if you are, you use an alias so that it’s shorter and easier to use.
This is exactly my point. I use git every day on the command line. I have ZERO aliases for it (seriously). If my source control tool has reached the complexity where I feel like I need an alias for commands in it... it's gotten too powerful. And git is definitely not "off the hook" here, it's absolutely got the same deep end, and if you live in that space, sure - jj might be really nice. But I strive to avoid living in that space.
basically: I don't want to do jujitsu, I want to do the occasional somersault and call it a day.
So, as a long-time mercurial users, revsets in jujutsu were a major feature for me. And if you don't want to use them, don't. But if you are looking to treat your VCS DAG as a queryable database they are awesome. And, they are great for avoiding having to chain a bunch of commands together, inefficiently, to get the same effect. Although you still can do that if you really want to. Just like you don't have to use jq to query JSON - you can do terrible cursed things with grep and awk and sed and it'll even work for simple cases. But you might want to give jq a spin - and really there are strong parallels in how they work.
> Basically - the vibe I got from it was: if you're a person who really likes making checklists, or complex tickets with subtasks and groupings and labels - jj is something you're going to like. If you're just interested in writing code and not so interested in source control outside of the ability to occasionally "snapshot this folder"... it's probably not going to be your thing.
This is a bizarre take, as most jj users just take your paragraph above and do a s/jj/git.
The benefit most people find in jj is that you can do stuff easily without having to think much.
There is no separate concept for stash and index (and yet you still have them in jj, and use them without giving them special names).
In principle, there's no real distinction between merge and commit.
You don't need to know the difference with/without --hard for git reset. You just do a "jj undo" no matter what.
Merge conflicts are not stress inducing. And if you're in the middle of an ugly merge conflict, you can just say "Screw it all" and quickly get back to before you did the rebase/merge - just keep hitting "undo" until you get there.
jj literally has a much smaller cognitive overhead than git does.
I also have zero aliases for git, and for jj. (I used to have one joke alias.)
That said: you should use the tools you like to use.
First of all: you do you and as long as you are happy, I am happy.
`jj` is a tool trying to amplify the strengths of git and strengthen its weaknesses. `git rebase` being just one of the many quirky commands. Yes, `jj` requires some rewiring of your brain, but once you get over the initial bump its pretty slick.
Also, I use `jj` everyday exclusively. And I have written `revsets` like 4 times in total.
i mean i can throw a million cryptic git commands at you, too (jj revsets can be arcane, but they're also fairly well-documented and the names are fairly descriptive). git's gotten a lot of usability features over the years, but there's still a ton of stuff that's just confusing. jj ends up being a lot more intuitive in practice IMO, though the anon branch thing does take some getting used to. there's a lot more i'm comfortable doing in jj, without that 'defusing a bomb' feeling complex git operations often had for me.
I assume you don't mean Tangled is an expert martial artist. Can you translate this to not-a-dev-but-uses-git?
They’re referring to the Jujutsu VCS https://docs.jj-vcs.dev/latest/
Jujutsu is a git-compatible version control system
oopsie; should have added links.
`jj` is a wrapper around git and offers a much better dev-ex for managing changes.
it has features like:
- conflicts are first class citizens
- `rebase` is the default mode; there is no need for an interactive rebase mode.
- all descendant changes automatically rebase
- a much more intuitive version of `git reflog`. in `jj`, we have `jj op log`
- cheap branching: branches in `jj` are just tags (or bookmarks) that can be moved around
jujutsu is a different version control system: https://www.jj-vcs.dev/
Is there really nothing like BitTorrent for git, or have we just not heard about it because of GitHub's network effects? It feels like this problem was solved long ago for binaries.
There is! https://radicle.dev :)
From today:
HardenedBSD Is Now Officially on Radicle
https://news.ycombinator.com/item?id=47944864
the fact that you, as the creator of a "competitor", post this as-is without a "At $co, we…" run-on is a good look
Oh, that's pretty cool! Now I can't decide whether that approach or one based on AT is better...
Pick whichever. We <3 the Radicle team and they're admittedly solving a much harder problem (gossiping git!) and rather elegantly at that.
Yeah I’ve met the Radicle people a couple times. I’ve never given it a thorough review but, for their goals, their designs have always seemed strong, and they’re pleasant people to chat with.
The main difference was atproto wanted to tackle scale, so we went with a servers & aggregation model. Radicle is going for device-to-device networking as a primary goal.
Do you think it will be possible to use them together? Having some sort of unified distributed system is intriguing to me. (e.g. can the Radical foundation and AT-proto foundation integrate, even?)
There is also ForgeFed/vervis
gittorrents were talked about and built at least 15 if not 20 years ago.
the issue isn't mirroring of data, this is a solved problem. everything else that a forge does is a problem - issue tracking, PRs, reviews, CI/CD, authn, authz, secrets, audit trails, ...
BitTorrent also enabled search engines to be built easily, which created discoverability. Unfortunately it's a much harder problem for git repos, especially when competing with GitHub search.
Radicle may be what you're after
Git is already distributed by itself. The management-part is what's missing (mergerequests, permissions, issues..), and it's disputable whether this is really necessary, or just a nice to have.
I'm confused on what exactly we need to add to decentralized git to get where we want to be - if it's identities, why aren't we using what git itself supports (gpg keys; if someone has your private key, they are you no matter where)?
Or in other words, what specifically does GitHub "do" that can't be done by using git as a backing store?
As a project member, I want users to already be logged in to the bug tracker. The lack of friction, likely from being the network effect winner, is key. I know fossil has this, but people don't have their private keys in fossil, they (I) don't even have fossil installed.
Whatever happened to OpenID, anyway? That was supposed to be federated one-click login. If the problem is login, then only the login needs to be federated, and this approach leaves the rest of the system more flexible as sites can have different bug tracking features without becoming incompatible with the federation.
Apparently there are two competing ID federation setups, and a bunch of "login with Google/Apple/Facebook/ID.me" and nobody can agree on anything.
I think it's just nice to have things in a central place ; no one's really gotten decentralized tech right and things like discoverability, interaction, job running, etc. is really nice to have in one place.
Mastodon and email are the closest I've felt to a distributed system that works, but for oss stuff ... I think we're getting closer, but it's still a very hard problem to solve.
> gpg keys; if someone has your private key, they are you no matter where
how would you rotate such a key and still convince everybody that you are still you?
> Or in other words, what specifically does GitHub "do" that can't be done by using git as a backing store?
how would you build a social graph of follows/stars and what not using user-owned git repos as a backing store?
GPG key rotation is a known issue with solutions (hint: it involves multiple keys) - https://danielpecos.com/2019/03/30/how-to-rotate-your-openpg...
> how would you build a social graph of follows/stars and what not using user-owned git repos as a backing store?
I'm just spitballing and depending on how you want to display it, you may need more - but if I want to "follow" you I submit a signed commit to your "follow" repository, similar if I'm staring a repo; and then your system issues a signed commit back to my "followed" repo.
People need more than a VCS. A way to search all of open source project's code, issues, and pull requests. A way to distribute software releases for free. A way to share code snippets. A way to discover new projects. A way to see what your friends are working on. An issue tracker and pull request area that is easy for users to submit through.
Last time I tried Tangled they had no concept of private repos. That’s the only thing keeping me on GitHub (oh, and my massive likes collection, I use those as bookmarks).
I’m self-hosting with cgit, maybe I could move my private repos to SourceHut? Idk.
There's an AT protocol working group for private data: https://atproto.wiki/en/working-groups/private-data
But you're right, the protocol doesn't currently support this.
Related:
Show HN: Tangled – Git collaboration platform built on atproto (1 year ago, 15 comments) https://news.ycombinator.com/item?id=43234544
Tangled, a Git collaboration platform built on atproto (6 months ago, 86 comments) https://news.ycombinator.com/item?id=45543899
Crazy... I actually hashed out a plan to begin bulding a successor to github earlier this week and this blog post describes EXACTLY what I was thinking about with atproto+git.
Good validation imho.
If you've got ideas for things Tangled doesn't do, it's all open source too: https://tangled.org/tangled.org/core
So you could theoretically either fork it and use it as a good starting point, or (even better) contribute the ideas you have straight into Tangled itself! :)
radicle.xyz also does the distributed/seeded forge setup and I think does a nice job of it already.
alternatively: https://radicle.dev/
This type of thing requires an economic driver to monetize the service.
I'd have a strong inclination to run such software if I knew that I was both helping host repos and getting paid.
Can't we really go back to pre-github model? I mean all it did was to reduce the barrier for contributions. With current flood of AI generated PR it doesn't sound like a big inconvenience to have to register at code hosting service used by project you want to improve/participate in.
I really don't understand this fear about a single pillar of failure, as people were in tears about the Ghostty thread yesterday. git is not GitHub. git is not HTTP. git is inherently decentralized with no concept of client/server. In git there is only local and a plurality of remotes.
That said the solution is simple. Open a secondary, or a new primary, account with another provider and add it to your project's list of remotes. Here:
If further explanation is needed see SO: https://stackoverflow.com/questions/42830557/git-remote-add-...Boom, problem solved: do it yourself redundancy/decentralization. If you want to make this federated then write a file containing a variety of remotes per addressed location and a script to dynamically update git according to your catalog at every location.
> Boom, problem solved
Not if your CI depends on github, or if you have specific actions to review things, or if you use SSO because you're an enterprise, or....
Workarounds exist for each of these cases, but they add significant friction. That's not terrible if you're one person, but if you're an org? big problem.
> or if you use SSO because you're an enterprise
Enterprise Cloud up time is 100% for last 90 days for most services, with a one being at 99.98 and one at 99.97.
Enterprise customers get an SLA
Most enterprises self host for all those critical things so they aren't blocked by third party service interruptions. SLAs might refund some money, but they won't recover the lost time.
I think this is less about source code itself, and more about the surrounding ecosystem of project management. Handling of issues, pull requests, who gets commit or admin access, all that stuff. If you mirror your git repo to other providers, fine. But if you have thousands of issues and PRs on Github, you still can't really move away and you still can't really work if Github is down.
Edit: I absolutely support federated forges, including Tangled as well as ActivityPub based approaches like the (slow) progress to federate Forgejo.
Projects are more than code. This doesn't solve the problem of issue trackers, pull requests, CI, etc.
Pull requests are a core feature of git, the protocol, so I think you probably mean certain PR features more than just PRs.
Issue trackers can be self-hosted from fully mature applications via docker images. You might find something here: https://selfh.st/apps/
CI is typically actioned from a configuration file in your repository to a CI SAAS solution, which could be anything. Travis CI was popular for a long time. When I was big into CI SAAS my favorite was Semaphore CI.
Thanks for the lead on the details, this has been on my spring cleaning todo list. Sounds like I have my weekend errand picked.
I was just thinking about forge federation this morning. It'd be nice to base the federation on email, which has been working fine for decades (boring tech and all that), and build UIs on top of it to facilitate collaboration.
Not everything needs to be federated. There is almost no benefit of having federated forges. Just self host if you want.
Lovely, so yet another promise to federate which will never materialise! Still going with the Drew’s reply in https://is.gd/5wwQy2 (yes, two years old, and he slightly softened his stand since then):
> SourceHut is already federated via email. We have no intention of adding ActivityPub support at this time.
Federated repositories is something very similar to paperless office, distributed authentication (OpenID), and distributed computing … it has been promised since forever, and nobody has ever seen it in the real life, and even less supported by somebody who matters. And yes, those who matter don’t help by sabotaging any efforts towards it.
hasn't distributed computing being around and successful for a long time?
nowadays it only cooled down, but that's far from "never seen"
Devault being a gigantic dick head has no bearing on whether or not tangled does things. If sourcehut wants to remain the isolated hermit of forges because the greybeards that be think it was better before, let them do so and remain their island of weirdos. We already do the same with the freebsd guys (except that freebsd is actually good and impressive unlike sourcehut)
Sourcehut does not matter, and federation of repos is already a real thing. The ones that don't want to federate just.. don't?
If we are going the distributed way, then why not host everything on a blockchain, instead of federating thousands of small instances?
I would be happier with my code distributely hosted on every participating node, rather than federating it on my crappy instance.
Also your wallet can be auth + sign so no need for third party auth layers
I don't think calling your git server a "knot" is going to go over well with certain large subsections of the OSS community.
Or rather, it will go over way too well.
Ha, we heard this but decided to stick to it because hey, it isn't hurting anyone. No harm in a little bit of fun.
Furry developers are all professionals and won't have a giggle fit every time they think about it.
I don't get the joke and I'm a bit too worried about googling this on my work pc, can you please enlighten me what's up with the word knot :D
The knot is the bit that causes two canids to get en-tangled after getting frisky.
In what sense do we need Tangled if there's already ForgeFed?
What a strange question.
Except there isn't already ForgeFed.
We need git-ssb
I really like the concept of federated social networks and it's the next thing I want to get into. Maybe even work on it as a job but I doubt there are any that pay well.
I think sovereignty over what information you consume is more important than ever. I had to use Twitter for work to get news about <topic> but the amount of virulent propaganda, totally unrelated to <topic>, that you end up absorbing is unforgivable. Even if you think you're smart and don't pay attention to propaganda, by design it hits you at the subconscious level so you can't block it. The only social media I have left is LinkedIn and I really hate it but it has made a direct positive material impact in my life ($$$) so I try to hold my nose while I use it. I really would rather use some kind of federated LinkedIn, but when I last checked nothing like that existed yet.
Why do we need to stick to Git? We need better tooling around the Patch Theory-based VCS which are better for decentralized working to begin with.
Immutable commits seem like a pretty good base for a decentralized VCS for me. In fact, Git was designed for this use case in the first place.
The snapshot-based system requires that the patch order matters which Darcs/Pijul don’t require so long as the patches apply since they commute. This means you can pull in patches from other users at an time in any order & still get the same stable reference. If you apply patches in a different order in Git, you will get a different reference hash & some entity ends up needing to be the centralized source of truth when doing deployments & stuff—which is probably why everyone ends up having some code forge for their code base on a centralized server to “sync” the state.
And with rebase, how are the commits immutable? Seems like MS GitHub found a way to mutably drop commits recently…
Oh! Posted some replies here, but: I forgot to mention one other incredibly awesome atproto based social coding decentralization system! Jeremie Miller's v-it, which lets folks share "caps" changes, "vouch" for each others caps, share skills. https://v-it.org/
It's so so so early. But I love how it moves from a world of maintainers & pull requests to a more ambient "this is what is working for me". I think this really is a next kind of leap. I don't know if we can keep relying on maintainer folks to guide each project forward like we have, if our agentic selves can be bandwidth limited & still go where we need to, channeling all our energy through individuals.
We need a federation of maintainers. A distributed of maintainers. Maintain ought be social. Tangled is great and I hope we can go beyond federation to many tangled, to widely widely tangled. And I hope we can go past maintainers too, past pressuring single people to have to decide it all. I think v-it really preceeda such an interesting agentic leaping off point that we are at, so interestingly.
This looks cool but the issue github is dealing with is exponential usage. They're trying to 30x their capacity right now - let that sink in! Microsoft here or there, any company would be struggling under this load. And I frankly don't think that any ideology driven alternative will ever be able to provide better uptime under the same load - or any alternative period, for that matter. We're just living in times where everyone is catching up with the capabilities of agents, and it was obvious that things like this will happen 12 months ago. Good luck for your project though!
I agree that any company would struggle in such case. The thing is that everyone see that GH is pushing for more agents, their Copilot thingy, and AI everywhere, while basic functionality that people relies on is constantly failing.
If you push a lot of new features but your baseline is constantly failing, then something is wrong.
If you're seriously using agents, you'll know that if they didn't offer that then people would rapidly switch platforms if they didn't. Maybe not all of them yet, but soon it will be all.
Switch platforms to what?
Switch to a git provider that offers agentic augmentation of your workflow. And I don't necessairly mean the way it works right now - it's being refined & adjusted & infrastructure is being built as we speak.
For example, in our company, most commits on main currently have 3-5 authors (we squash): 1-2 humans, 1-3 agents (cursor cloud agent getting started, ppl pulling it into cursor locally to continue, then review using copilot review, modify using copilot agent) then use a vibe coded github app offloading UI test execution to a beefy baremetal machine to adjust baselines.
Copilot review in particular is just so good, better than any agent i know (incl opus 4.7). It just allows you to skip the first few review rounds by humans and fix simple but hard to spot logical bugs, keep docstring & style up to date across the codebase, before you give it to a human - which means everyone can focus on writing more code.
Setting all of this up, at a massive scale, is just not feasible for any of these projects.
You frame the symptom as the problem though. Others seem to be attributing this to Azure migration and Copilot overhead tightly coupled to GitHub infrastructure.
No the problem is that github has to stem exponential usage increase and prepare 30x of their capacity, that's not symptom, that's problem.
It's both and, it's a symptom of exponential usage and a problem with infrastructure. The question you aren't asking is "Why is it a problem with GitHub's infrastructure?" the answer to that lies somewhere in between: Microsoft + Azure + Copilot. Now tell me which of those have anything to do with GitHub as we know it?
Why is it a problem with Githubs infrastructure!? Bcs any website on the planet will struggle when they have to fulfill 30x capacity within 1-2y, no matter which tech stack they're built on, including federated networks. I'm not sure why you're throwikg Copilot in there, you don't like it?
Github as we know it is gone, forever, it will never come back, except for niche hobby clones with .001% capacity that nobody will use. Agents are re-defining what software engineering means, they already have, right now,and are continuikg to do so, it's just that hackernews is lagging 6 months behind for some reason.
I guess you’re right, in part I’m attributing the growth to Copilot and over prioritization of it alongside the AI feature factory galore and that’s where I’m coming from, but thinking again a lot of the acceleration of normal usage comes from AI usage through other vendors ending up in GitHub too.
I don’t know their internals, though clearly they choose to tightly couple every major GitHub system to the AI offering, in my eyes that seems like part of the problem (plus Azure cloud migration on top because Microsoft sounds like a disaster).
Anyways, you sound angry.
Not with you, just a little frustrated with the general vibe and tone in hackernews :) Nad it's not anyone's fault either everyone is just doing their best to follow what's happening. But I think hackernews is currently way off base when it comes to what's really happening, which is kinda sad considering it use to be "the place" to see what's currently going on. The AI revolution is here, anyone that's cussing about claude code max for 100/month getting rate limited doesn't understand it's already with 2k/month, everyone who's upset that github is focussing on copilot doesn't understand that this is the single modt important product they have to jump on asap or geit their lunch eaten by base44, cursor, linear etc.
I like to talk trash about Microsoft as much as anyone, they made insanely bad product descisions in the past (copilot in ms word is one of many) but this is not one of them.
Slight tangent: the post says that github is crumbling. Can someone get me up to date on what's going on please? Admittedly I'm not following tech drama particularly closely, but I thought I'd have heard if a major thing like github was going down the chute.
So there has been increasing issues form the github side for the past year and I believe they also just lost alot of customer/user data on top of several critical vulnribilities and bugs in base service and in actions.
My POV: Github actions are inconsistent in billing, security and require alot of attention to do right. Github has worse uptime than alot of free online videogame services, when most enterprise and business world leans on it for developers. Leaving a lot of users with terrible experience the past year having to constantly examine github firefighting for issues around availability, security, and billing instead of doing work that makes the company/people money.
Example walk through of securing github actions for ci/cd and managing SBOM python dependancy/supply chains (giant complexity) [1], Github has remote code execution[2], Uptime by 3rd party tracker shows 86% past 90 days. (First quarter in 2 years where they didn't have atleast one month above 90% uptime) [3]
[1] https://astral.sh/blog/open-source-security-at-astral [2] https://www.wiz.io/blog/github-rce-vulnerability-cve-2026-38... [3] https://mrshu.github.io/github-statuses/
A simple search holds the answers https://hn.algolia.com/?dateRange=pastMonth&page=0&prefix=fa...
It’s had horrific uptime, to the point of hitting 88.x uptime percentage.
This is likely on the back of Mitchell Hashimoto (Hashicorp founder) announcing he’s moving off of Github as well.
And really just years of Github feeling inconsistent, bad UX, no good solutions for open source developers in terms of AI spam etc.
> but I thought I'd have heard if a major thing like github was going down the chute.
Wow, it was a really long time ago it started going down the lane of the chute, can't believe someone missed it, made big news at the time back in 2018! This was the turning point: https://news.ycombinator.com/item?id=17221527
88% uptime, search index incident, CVE's to name a few.
Check a local repo and go to pr's, there's a big banner telling you there's an ongoing ncident
https://www.githubstatus.com/
In particular:
https://www.githubstatus.com/history
Github has frequent downtime: https://mrshu.github.io/github-statuses/
https://news.ycombinator.com/item?id=47940921
A federation of forges makes no sense if everything gets centralized again in the hands of the people operating Tangled (sure, someone else could run an alternative AppView, but then if you are only on the alternative you are invisible to anyone who is only on Tangled).
https://gitgrasp.com/ fixes this.
The problem with GitHub is from ... we all know it...
AI.
They're working on the scaling issues apparently due to huge demand.
I'm sorry but I will never use this. I don't want a federated protocol and I absolutely do not want "social". The Git protocol is enough to distribute my source code to any Git server, so that part is complete. What I need, in addition and separate from Git, is a standard API schema for all the other SDLC bits: CI/CD, PRs, Issues, Packages, Containers, Branch Protection, etc. The API should not be a specific transport implementation, like HTTP, or AT. It should merely describe the schema, and then you implement that schema on anything else.
"createIssue(title=string, body=string, labels=[string])" would be the same in Git's source code as it would be on a REST API server. The point of this is to standardize the software development lifecycle everyone uses around Git. That way you can do all the work we all need, with any VCS, without tight coupling. That's been the missing piece that nobody has made yet.
Want just the CI/CD component? Use that part of the schema. Want just the Issues? Use that part of the schema. Now you can write any tool you want, and just implement the features you want, and say "this follows the SDLC v1 CICD standard", or "the follows the SDLC v1 Issues standard". Much simpler to add extensions or support different use cases, without implementing everything you don't need. Yet everything's compatible.
We need that implementation-agnostic standard, so we can make transport-agnostic protocols, so different providers, clients, and servers can all talk to each other, without a hundred different bespoke "things". Rather than write your plugin-downloading app only against GitHub or against Federated-Whatever, you write it to use "httpSLDCs://some-server/v1". Don't want to use https? Use "grpcSDLC://some-server/v1", or "atSLDC://some-server/v1". You layer the application-specific protocol on top of the transport protocol, and express that in a URL. That's how we did 'federation' in the 80's/90's/2000's.
(also: did nobody come up with a better name? Tangled? Knot? you want your solution to be a tangled knot?!)
If only git was a distributed system!
People tend to focus a bit to much on the Git part of Github. Git is already relatively fine. It's nice to have a web view into the repo, users can just clone the repo, but many seems hesitant to do so as if it's some major operation (it can be for large repos, but normally it's not).
The tricky part is the bugtracker and pull-requests. I don't really know how I feel about the Github issue tracker. In theory it's a good way for a community to report and manage bugs, but it's also what's driving maintainers crazy. Previously, in the olden days, you'd send an email to a mailing list and maybe get a reply, maybe got told to show up with a patch or bugger off.
To some extend Github removed to much friction, and while quick drive by patches can be great, they don't build much community.
Personally, I prefer mailing lists. The tooling is there, it's consistent, and it's powerful. And if it adds a higher bar of entry, in this day and age that seems like a plus to me.
it is - but dealing with code involves a lot more than just git.
tangled distributes the rest of the stack - issues, comments, pulls, stars, etc.
Please don't give your users a nickname like "tanglers", groups come up with their own nicknames. It's not as infuriating as when New Relic started calling everyone "Data Nerd", which is actually offensive to me and weirdly aggressive for a corporate product.
> Please don't give your users a nickname like "tanglers", groups come up with their own nicknames.
What prompted this? I can't see "tanglers" in the OP. Did you see them calling their users "tanglers" somewhere? Honest question.
It's on the homepage under "Recent updates".
Tangled is VC funded just like initially how GitHub was:
https://blog.tangled.org/seed/
It always ends the same way.
enshittification.
Also:
> Bain Capital Crypto is an investor.
A crypto VC is invested in this.
This is not the solution.
You completely missed the point. The point isn't that you should find a company that you trust and think is ethical. The point is to shift the power dynamics so you don't have to trust anyone. That's what building on ATproto does. Tangled is also fully open source and anyone can host their own knot and AppView.
I don't have a vote on whether ATProto is a good foundation to build such a thing, it seems to me rather that git has quite a bit of relevant machinery inside already, and maybe it might be extended a little, if only by convention.
but your overall point is extremely valid. lurching from garden to garden is just stupid for something so critical and core to the way software is developed. there should be a meaningful core standard for the data (the commits, PRs, workflows, etc). If people want to innovate and change on top of that great.
that's how GitHub started, but they flattered and turned the screws and convinced everyone that using them was the only viable workflow. for that matter can't we revisit the notion of a 'forge', that's really some product marketers version of how things should work and be bundled and charged for, not anything fundamental.
You seem to have missed the fact that Bluesky is funded by the same crypto VC.
Look how well that has turned out even though Bluesky is open source.
Tangled is not funded by the community.
It would be better if it was rather than it be owned by VCs.
> Look how well that has turned out even though Bluesky is open source.
??? Bluesky can make decisions, mistakes, or moderation choices you disagree with and you can just go to https://blacksky.community, a completely independent AppView with different moderation that was up for the entirety of a 24hr outage Bluesky recently had.
I'd say AT Protocol is turning out pretty well.
> ??? Bluesky can make decisions, mistakes, or moderation choices you disagree with
Bluesky PBC still has major influence of the AT Protocol.
> and you can just go to https://blacksky.community, a completely independent AppView
Swapping one broken chair for another broken chair won’t cut it.
Development and steering is subsidised by VCs funding Bluesky at this point. (especially a crypto VC)
Have you ever asked whats in it for them?
What plans are they going to put into the protocol?
I can see the AT Protocol shoving crypto payments or whatever in their insatiable quest for growth and ROI, because when the funding money runs out when BS miss their growth targets, this is what happens.
And for Tangled’s monetisation path, it is questionable.
So no.
Not a solution.
I only use GitHub for unified login git access to a bunch of repos. These other “forges” (didn’t know that was the term - cool) are all almost certain to put Anubis in front and make a logged out user be unable to access the code. I get why, but it seems inevitable. I think Codeberg already does and for some reason it takes ages to complete the challenge on my phone.
Undoubtedly these various hosts will come under pressure from spammers and the like and they will react by placing extraordinary barriers around accessing the code.
That’s fine but it reminds me of the later stages of online forums, where it was impossible to browse most threads because you had to create an account and then build up community points until the screenshot of the kernel panic on the ZTE phone would be visible so you could see if it’s the same problem as yours.
GitHub was big and powerful enough to not need all of this but now we’re going back to the era of decentralization and I suppose with that come the pros and cons.
reminder for anybody who might be interested: tangled is built on ATProto and when the bsky devs went public in saying "fuck the users", one of the tangled co-founders chimed in right along side them.
it's one thing to use the protocol of libertarian dickheads in the hopes of extracting it from them, but when it's done by other libertarian dickheads, there's not much chance of that outcome.
on balance, though, the tech appears solid. as in, it does what they claim it does and that is mostly what devs seem to need. if you're not interested in who you're giving your content to, at least tangled has the functionality that they're offering your content in exchange for it.
definitely in favor of git federation, and while I would prefer that it happens using git and only git, rather than another protocol on top of it, I get the feeling that there are at least some things that git wouldn't handle well that people would still really want, so I can understand why so many would reach for a wrapper protocol instead.
RESPONSE EDIT (clear and intentional rate-limit evasion):
hayden_dev: not going to dig up the specific source, but you can search for "bluesky" and "waffles" to find the offending skeets (or the dramatic thinkpieces about them), and you can read the responses to those skeets yourself, where you can find the tangled dev/cofounder.
psionides: hey, to each their own! I'd never ask you to call anyone a libertarian dickhead. and I'd also never begrudge your your opinion of someone you've personally exchanged comments with, even if I didn't agree with that opinion based on the comments I had exchanged with them. you do you, friend!
to anyone else that thinks they are... uh... "exposing" me... ? let me be clear in my bias: fuck the AT protocol - not because it's bad, because the people who made it are dickheads that are more interested in pretending they're building the future than in actually delivering a social product for human beings. They're not unique in this; in fact they are in very common company. most silicon valley types, especially those borne out of the largest social media companies in the world, prefer to make 'perfect systems', rather than actually engage with the imperfection of human social dynamics. but, to be clear, my condemnation for them is not unique to them either. I consider the heads of facebook, and google, and adobe, and microsoft, and pretty much any other large software company dickheads, too.
just because everyone sucks doesn't mean I'm wrong to say they suck. nor does it make me wrong to specify that THIS ONE sucks, without necessarily caveating that with "and all the others suck too, and maybe less". my problem is the seemingly endless loop of tech bros saying "well, it's the best we got, and they seem fine, so we'll make do with what they're giving us", and then eventually those same tech bros shrugging their shoulders when the whole thing falls apart because of libertarian dickheads and their priorities. We're at the start of the loop with ATProto, but for a look at the end of the loop, see the consensus on github today.
catpart is definitely NOT someone with a long history of railing against anything vaguely connected to ATproto: https://news.ycombinator.com/item?id=46670016
catpart has totally 100% provided a citation for the "fuck the users" moment (sike): https://news.ycombinator.com/item?id=46672904
the actual "fuck the users" moment is described here [4,3095771], wherein a group of activists failed to get a person (Jesse Singal) they deemed unpalatable deplatformed from Bluesky, mostly by claiming that this person broke the ToS, and the Bluesky moderators mocked the activists in public.
[4] https://techcrunch.com/2025/10/05/waffles-eat-bluesky/
[3095771] https://en.wikipedia.org/wiki/Jesse_Singal#Subsequent_events
This is incredible. Thanks.
in your world, literally who isn't a dickhead? yourself, presumably? you must make a living somehow.
nah, I'm you're run-of-the mill dickhead, I'm afraid. righteous and principled but ignorant and overbearing. classic asshole, by nature. doing my best to be better every day, though. hoping the same for everyone else.
as far as who isn't, the first names that come to mind are Fred Rogers - he seems like kind of the summit of what a soul can aspire to be. Randall Munroe seems like a pretty awesome guy. Haven't looked too much into him, though. most names that come to mind are personal acquaintances that wouldn't mean much to you, but I find that it's not very difficult to find non-dickheads in my day to day life. probably around 30% of the people I encounter in passing are a-okay in my book! but it is true that the number of dickheads I encounter skyrocket when I start approaching cultures that glorify personal gain over community success and health. abstract or practical; the business community is rife with awful people and los angelos is terrible for entirely different reasons.
anyway, yeah. I make a living. dealing with wonderful people who have a shred of humility and who - when they get called out - just sheepishly say "oh! wow, that is awful. I'm so sorry for saying/doing that." and everybody moves on with their business. I hope you work with wonderful people as well!
source for the fuck the users quote please lmao
I don't think there's a good reason to call the creators of Tangled "libertarian dickheads", tbh.
If anything starts with "we need" I just laugh.
We need more humor in the world
I'm hesitant to build anything load-bearing on AT Protocol given its PQ exposure: https://words.filippo.io/crqc-timeline/
They're aware of it.
https://bsky.app/profile/bnewbold.net/post/3miufj3cfhs2i
How does this impact AT Protocol? I’m just hearing about AT now, so I’m not familiar
Today, not so much. But once the day is here where we have CRQC, if ATProto hasn't yet started using post-quantum cryptography for identities, users are either vulnerable or a bunch of stuff will break once they push a hotfix to make users not vulnerable.
Alternatively, they fix these things now, so once CRQC arrives, it's already not a problem, and no gets compromised nor have to urgently update their software.
I'm not sure it says much, but I met the person who wrote the post you linked to at ATmosphere this year. To me that says that maybe they're not as worried as you about ATProto's PQ exposure. I overheard lots of discussions about the topic, but I'm not an expert so I can't give much more insight than that.
Why not Just™ store all PR/Issues content as markdown on a separate branch along side the code itself? Why do we need a new protocol?
Developers don't want to have to deal with merge conflicts or silent auto-merge failures in their issue tracking.
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 desirable for some reason.
The "some reason" isn't mysterious... it's redundancy and avoiding a single point of failure and ownership.
But the actual git part isn't federated
Git itself is already federated. Every clone is a repo. That's not the bit that needs fixing.
so you would consider fossil a fully realized version of this?
except it isn't at all like ActivityPub and is implemented radically differently to avoid many of the problems with ActivityPub.
I was saying at protocol is to bluesky as activity pub is to mastodon
So it's as if all the github pull requests were tweets, I guess?