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?
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
"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.
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.
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 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.
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.
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?
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.
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.
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.
> 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.
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.
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.
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)
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.
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).
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.
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 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.
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.
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.
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.
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.
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.
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.
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 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.
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'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?!)
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.
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.
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?
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
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.
> 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.
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.
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?
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.
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.
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.
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.
> 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.
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.
just wanted to share how much i loved this blog post :)
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.
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.
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.
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
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.
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.
[delayed]
> 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?
"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.
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.
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
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 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
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.
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.
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?
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 post 2025 is the question.
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.
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.
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 ;))
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.
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?
I don't mind VC funding as long as they aren't YC funded.
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.
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.
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.
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.
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:
They do if you want to collaborate with others. No one is going to want to create accounts on your personal instance
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.
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.
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.
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.
Radicle may be what you're after
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.
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.
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.
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/
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 git-compatible version control system
jujutsu is a different version control system: https://www.jj-vcs.dev/
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.
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.
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.
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.
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.
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.
Thanks for the lead on the details, this has been on my spring cleaning todo list. Sounds like I have my weekend errand picked.
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.
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.
radicle.xyz also does the distributed/seeded forge setup and I think does a nice job of it already.
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'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?!)
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.
In what sense do we need Tangled if there's already ForgeFed?
Except there isn't already ForgeFed.
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.
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?
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.
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?
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?
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/
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
A simple search holds the answers https://hn.algolia.com/?dateRange=pastMonth&page=0&prefix=fa...
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
If anything starts with "we need" I just laugh.
We need more humor in the world
If only git was a distributed system!
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.
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.
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'm hesitant to build anything load-bearing on AT Protocol given its PQ exposure: https://words.filippo.io/crqc-timeline/
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.