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

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.

It’s a bit long but should give you a really crisp picture.

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.

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)

Even though it's federated, when development stops, who will be there to fix bugs and maintain it?

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.

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.

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.

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.

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

Git IS the federation layer in this case.

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.

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.

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.

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.

Or rather, it will go over way too well.

Or in other words, what specifically does GitHub "do" that can't be done by using git as a backing store?

I’m self-hosting with cgit, maybe I could move my private repos to SourceHut? Idk.

Good validation imho.

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

https://gitgrasp.com/ fixes this.

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:

    git remote add <name here> <URI>

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.

As long as it’s like Steam and stays private it’ll be fine.

I'd have a strong inclination to run such software if I knew that I was both helping host repos and getting paid.

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

AI.

They're working on the scaling issues apparently due to huge demand.

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

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.

"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?!)

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.

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.