HN

Comments (255)

• Menu

  rafram
  How will this end up going any better than Mastodon has?Near inevitabilities:- All the small instances defederating from the largest due to politics/spam/annoying noobs/whatever, effectively killing the easiest path to entry into the community- Pointless debates about whether it’s OK to federate with instances that host pirated content, disagreeable politics, furry VNs, etc., which everyone has to take a side (the correct side) on- Relatively little actual work/productive discussion going on, since many users are there mostly for the politics / fediverse posturing than for actual work
• Menu

  FatFingers23
  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.
• Menu

  willio58
  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.
• Menu

  danabramov
  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.
• Menu

  4lx87
  Looks really cool but ATProto means I won't be using it. I'm not going to invest in another network when we already have an open one.We already have the web. The web already has OAuth. OAuth is already widely supported. IndieAuth already offers a very simple and standard approach to personal OAuth servers, if people really want to run their own identity server."Feeds" are perfectly doable using the web. It's already pull-based. We don't need another protocol to listen for changes at a URL. The web already has support for different content types and document schemas, we don't need to reimplement content types and schemas as ATProto "lexicons".
• Menu

  jonstaab
  I don't know how new Tangled is, but there is a fairly mature github alternative being built on Nostr:https://gitworkshop.dev/The basic idea is that you can put your repository on multiple GRASP-compatible nostr relays (GRASP is a sub-protocol that glues nostr and git together), so even if one server goes down you can transparently sync using the others. This means in effect 100% uptime if you choose reliable servers, as well as cryptographically-signed repositories, activity, issues, etc.
• Menu

  madamelic
  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)
• Menu

  jerojero
  "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.
• Menu

  code-blooded
  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?
• tardedmeme
  A federation doesn't mean the forges talk to each other. It only means there's more than one, and data flows between them. This can occur by developers pushing and pulling from different remotes. You already have a different remote for each fork, you lose nothing if they're also on different servers. Communication about the project can also happen in many places.
• Menu

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

  noirscape
  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.
• praseodym
  Forgejo also has a roadmap for federation but it looks like development is progressing rather slowly: https://codeberg.org/forgejo-contrib/federation/src/branch/m...
• Menu

  ecshafer
  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.
• Menu

  divbzero
  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?
• Menu

  delf
  GitSocial allows cross-forge collaboration without any 3rd party dependencies as it keeps everything in git: <https://github.com/gitsocial-org/gitsocial/blob/main/documen...>Git IS the federation layer in this case.
• Menu

  999900000999
  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.
• altairprime
  Related:Show HN: Tangled – Git collaboration platform built on atproto (1 year ago, 15 comments) https://news.ycombinator.com/item?id=43234544Tangled, a Git collaboration platform built on atproto (6 months ago, 86 comments) https://news.ycombinator.com/item?id=45543899
• Menu

  bombcar
  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?
• Menu

  d_silin
  Federated solutions seem to be the future, after once-beloved provider becomes the crumbling monopoly.
• Menu

  ghc
  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.
• Menu

  whereistejas
  tangled is a really cool project; the most important feature it provides is that it is jujutsu first.
• Galanwe
  If we are going the distributed way, then why not host everything on a blockchain, instead of federating thousands of small instances?I would be happier with my code distributely hosted on every participating node, rather than federating it on my crappy instance.Also your wallet can be auth + sign so no need for third party auth layers
• Menu

  NetOpWibby
  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.
• Menu

  carrja99
  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.
• bfrog
  radicle.xyz also does the distributed/seeded forge setup and I think does a nice job of it already.
• CWwdcdk7h
  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.
• Menu

  austin-cheney
  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: git remote add <name here> <URI> 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.
• Menu

  mcepl
  Lovely, so yet another promise to federate which will never materialise! Still going with the Drew’s reply in https://is.gd/5wwQy2 (yes, two years old, and he slightly softened his stand since then):> SourceHut is already federated via email. We have no intention of adding ActivityPub support at this time.Federated repositories is something very similar to paperless office, distributed authentication (OpenID), and distributed computing … it has been promised since forever, and nobody has ever seen it in the real life, and even less supported by somebody who matters. And yes, those who matter don’t help by sabotaging any efforts towards it.
• galbar
  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.
• yodon
  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.
• zeafoamrun
  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.
• renewiltord
  I only use GitHub for unified login git access to a bunch of repos. These other “forges” (didn’t know that was the term - cool) are all almost certain to put Anubis in front and make a logged out user be unable to access the code. I get why, but it seems inevitable. I think Codeberg already does and for some reason it takes ages to complete the challenge on my phone.Undoubtedly these various hosts will come under pressure from spammers and the like and they will react by placing extraordinary barriers around accessing the code.That’s fine but it reminds me of the later stages of online forums, where it was impossible to browse most threads because you had to create an account and then build up community points until the screenshot of the kernel panic on the ZTE phone would be visible so you could see if it’s the same problem as yours.GitHub was big and powerful enough to not need all of this but now we’re going back to the era of decentralization and I suppose with that come the pros and cons.
• Menu

  bkummel
  In what sense do we need Tangled if there's already ForgeFed?
• Menu

  estimator7292
  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.
• collinmanderson
  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?
• toastal
  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.
• fiatjaf
  A federation of forges makes no sense if everything gets centralized again in the hands of the people operating Tangled (sure, someone else could run an alternative AppView, but then if you are only on the alternative you are invisible to anyone who is only on Tangled).https://gitgrasp.com/ fixes this.
• Menu

  ddosmax556
  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!
• Menu

  short_sells_poo
  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.
• firebot
  The problem with GitHub is from ... we all know it...AI.They're working on the scaling issues apparently due to huge demand.
• Menu

  kordlessagain
  If anything starts with "we need" I just laugh.
• Menu

  Manfred
  Please don't give your users a nickname like "tanglers", groups come up with their own nicknames. It's not as infuriating as when New Relic started calling everyone "Data Nerd", which is actually offensive to me and weirdly aggressive for a corporate product.
• Menu

  calvinmorrison
  If only git was a distributed system!
• Menu

  colesantiago
  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.
• taintlord
  [dead]
• Menu

  catapart
  reminder for anybody who might be interested: tangled is built on ATProto and when the bsky devs went public in saying "fuck the users", one of the tangled co-founders chimed in right along side them.it's one thing to use the protocol of libertarian dickheads in the hopes of extracting it from them, but when it's done by other libertarian dickheads, there's not much chance of that outcome.on balance, though, the tech appears solid. as in, it does what they claim it does and that is mostly what devs seem to need. if you're not interested in who you're giving your content to, at least tangled has the functionality that they're offering your content in exchange for it.definitely in favor of git federation, and while I would prefer that it happens using git and only git, rather than another protocol on top of it, I get the feeling that there are at least some things that git wouldn't handle well that people would still really want, so I can understand why so many would reach for a wrapper protocol instead.RESPONSE EDIT (clear and intentional rate-limit evasion):hayden_dev: not going to dig up the specific source, but you can search for "bluesky" and "waffles" to find the offending skeets (or the dramatic thinkpieces about them), and you can read the responses to those skeets yourself, where you can find the tangled dev/cofounder.psionides: hey, to each their own! I'd never ask you to call anyone a libertarian dickhead. and I'd also never begrudge your your opinion of someone you've personally exchanged comments with, even if I didn't agree with that opinion based on the comments I had exchanged with them. you do you, friend!to anyone else that thinks they are... uh... "exposing" me... ? let me be clear in my bias: fuck the AT protocol - not because it's bad, because the people who made it are dickheads that are more interested in pretending they're building the future than in actually delivering a social product for human beings. They're not unique in this; in fact they are in very common company. most silicon valley types, especially those borne out of the largest social media companies in the world, prefer to make 'perfect systems', rather than actually engage with the imperfection of human social dynamics. but, to be clear, my condemnation for them is not unique to them either. I consider the heads of facebook, and google, and adobe, and microsoft, and pretty much any other large software company dickheads, too.just because everyone sucks doesn't mean I'm wrong to say they suck. nor does it make me wrong to specify that THIS ONE sucks, without necessarily caveating that with "and all the others suck too, and maybe less". my problem is the seemingly endless loop of tech bros saying "well, it's the best we got, and they seem fine, so we'll make do with what they're giving us", and then eventually those same tech bros shrugging their shoulders when the whole thing falls apart because of libertarian dickheads and their priorities. We're at the start of the loop with ATProto, but for a look at the end of the loop, see the consensus on github today.
• steffs
  [flagged]
• pasto421
  [dead]
• ctdinjeu4
  [dead]
• Menu

  0xbadcafebee
  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?!)
• Menu

  Croaky
  I'm hesitant to build anything load-bearing on AT Protocol given its PQ exposure: https://words.filippo.io/crqc-timeline/
• Menu

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