4 ms·
What really stands out to me in this migration story isn't the technical side at all, but the reminder that "feature parity" isn't the real hurdle here. Codeber
by Emen15 11mo ago
What really stands out to me in this migration story isn't the technical side at all, but the reminder that "feature parity" isn't the real hurdle here. Codeberg is already good enough for most day to day workflows; what it doesn't have is the gravitational pull GitHub built through network effects, integrations, and plain old inertia.
- kaferoni 11mo agoThis is partially being addressed by projects like https://tangled.org https://tangled.org. It's built on the same protocol as bluesky, meaning your identity is preserved across different platforms so that _where_ your git is hosted is unrelated to how you discover and connect with others.
- bayindirh 11mo agoFWIW, Forgejo (Codeberg) is also building federation capability [0]. [0]: https://codeberg.org/forgejo-contrib/federation/src/branch/main/FederationRoadmap.md https://codeberg.org/forgejo-contrib/federation/src/branch/m...
- jcgl 11mo agoUnfortunately it's most ActivityPub-oriented, right? Which means no name portability. That's a major shortcoming compared to an AT protocol-based thing like Tangled appears to be.
- zenmac 11mo agoNostr would being better. As it is truly free vs AT protocol is backed by VC.
- icy 11mo agoAT being backed by VC is false—it's Bluesky the company that is. AT is merely a spec for signing, storing and propagating structured data (records) + the identity that owns said records.
- arccy 11mo agoand who controls what goes in to the spec? still Bluesky.
- icy 11mo agoNot really. It's very open for everyone to participate. Further, Bluesky has been working on standardizing AT at the IETF [0][1]. They have also made a patent non-agression pledge: https://bsky.social/about/blog/10-01-2025-patent-pledge https://bsky.social/about/blog/10-01-2025-patent-pledge In short, they're actively working on making AT as neutral as possible. [0]: https://docs.bsky.app/blog/taking-at-to-ietf https://docs.bsky.app/blog/taking-at-to-ietf [1]: https://datatracker.ietf.org/doc/bofreq-newbold-authenticated-transfer/ https://datatracker.ietf.org/doc/bofreq-newbold-authenticate...
- zenmac 10mo agoWe have already talked about this. In the end it comes down the index for the instances that bsky maintain it will inevitably be the dominate ones vs others who run AT Pro. It would be all good if the index is shared via DHT, bittorrent, ips or other means. Same goes for the google search index, etc.
- jcgl 10mo agoYou're talking about Bluesky's ATProto instance (term.?). Other commenter is talking about ATProto as a protocol.
- jcgl 11mo agoI don't tend to believe in cryptokey-first protocols like Nostr, where your identity is tightly coupled to a keypair. Human identity doesn't work like that at all, and keypairs as the basis of identity will never be suitable for use by the masses. Human-readable names are far more suitable as a handle for identity as humans think of it. And DNS names are an okay-ish implementation of that. I think that a decentralized protocol that provides name portability based on the DNS is a far better protocol than one that relies on keypairs.
- deleted 11mo ago[deleted]
- Vinnl 11mo agoI don't think it's relevant to this specific instance, but AFAIK ActivityPub doesn't inherently prevent name portability. It's just that almost all implementations currently don't allow it (and I wouldn't expect Forgejo's either). Of course, the practical downside of Tangled is also that it only has network effects within the ATmosphere, i.e. you still can't reach GitHub users.
- jcgl 11mo agoFirst of all, non-standard extensions to federated protocols have a pretty rough history. Even when an extension reaches median adoption (rare, I assert), the long-tail adoption is dismal. For something as fundamental as Second of all, how could this just be an implementation-specific extension? The failure mode (of a client not supporting the extension) would be outright broken. To have name portability, the client needs a two-step to first discover the name's server before then connecting to that server. Whereas now (afaiu), the server is already identified by the name. That's a fundamental change in what identity means at the protocol level. I'd love to be corrected by someone more intimately familiar with ActivityPub. But until it has mandatory (and mass-adopted) support for something vaguely like SMTP's MX records or whatever the equivalent for ATProto is, name portability is a distant dream.
- Vinnl 11mo agoI'm not intimately familiar with the spec, so don't take my word as gospel, but as I understand it, current implementations already do name discovery. It's just that every implementation hardcodes the server name. IIRC some people have applied some kludge where they put a .well-known document on their own server to point to their instance's account, but it's still pretty spotty without that server being actively aware of that identifier. But (again, if I'm understanding correctly) servers could be updated/written to support that properly.
- jcgl 11mo agoNot to split hairs, but that sounds more like plain hackery rather than proper extension. Let alone a viable future. I don't doubt what you say that it's possible in the most technical sense of possibility. But actually possible, in this world where we live? No, doesn't seem like it.
- IgorPartola 11mo agoIf only we could use something like a gpg key as our identity. Maybe if it had a mechanism to share and revoke keys, upgrade them, cross-sign them with others to develop some sort of like trust system that was web-like. I bet we could like build a whole infrastructure around it to maintain developer identities in a completely decentralized way.
- akshitgaur2005 11mo agoHas any detailed comparision been done between tangled, codeberg and github?
- PunchyHamster 11mo agoAnd just sheer amount of documentation and examples out there. Everyone uses it, therefore everyone writes about it, the new hire probably knows it, and if they don't they can find it easily. Then again maybe for stuff like actions and in general CI/CD it's not all that bad, you don't need whole team to know exactly how to write it, you just need to have a person knowing it. and it's generally not all that hard to learn.
- Waterluvian 11mo agoIt feels like a <game theory> problem (Tragedy of the commons? First mover? I dunno them well enough). It’s probably a mistake for any one company to not pick GitHub, because it’s likely a higher friction distraction from what the actual goals are of the company. But enough companies paying that price ultimately would benefit everyone by fuelling stronger competition.
- crabmusket 11mo agoMaybe a coordination problem? https://en.wikipedia.org/wiki/Coordination_game https://en.wikipedia.org/wiki/Coordination_game
- Jaxan 11mo agoIt is a version of the prisoner’s dilemma.
- vovavili 10mo agoThe term you're thinking of is "collective action problem".
- IgorPartola 11mo agoThis is why CI should be separate from code repository storage and that should be separate from your collaboration tools. They all can speak git if you want.
- Marsymars 11mo ago
- markstos 11mo agoMy primary pain point with Codeberg has been that the issue search is worse, so that there are cases where I'm rather certain than issue exists-- because I've triaged it in the past-- but it's hard to find with the keyboard search. Hopefully that can be improved soon. There were some times were Codeberg's general performance was noticeably worse, but most recently it has been fine. If you thinking of migrating a project with hundreds of issues, I would do a test migration and practice a few different searches to test the result quality.