The federated code forge
34 points by novedevo
34 points by novedevo
Should be read in light of https://lobste.rs/s/htgcuc/do_at_proto_users_know_this_is_public
A forge with no privacy model at all doesn't appeal to me, although I can see it certainly has its uses.
FWIW, they are planning private repo support soon™: https://news.ycombinator.com/item?id=50307062
I haven't looked at which parts of source control they're federating, but one would hope that the developers have enough sense to enhance only the bits that are related to social interactions: change requests, reviewing, commenting, etc, not the repositories themselves.
If you had read to the end of the article you might have noticed that they specifically mentioned private repositories:
This isn’t all. We’re staggering this launch across the next few weeks. Up next are private repos, a CLI, SDKs for different languages and skills for your agent.
I have read the comments in there and doesn't the new ATproto spaces proposal solve this issue?
Is anyone more knowledgable about ATproto chime in here?
yep, the spaces proposal (now in alpha, and already has several implementations!) solves this. we (tangled) have done something very similar here for private repositories. there are many inprogress updates to the protocol (group accounts, permissioned data). we have developed implementations of these based on the proposals, and intend to upgrade to the spec when the spec stabilizes.
privacy model
what does this mean to you? is it similar to a threat model?
I mean how the design of a distributed system preserves the confidentiality of certain information that passes through it. My understanding is that atproto is not designed to preserve privacy, although I'm aware (and skeptical) of some proposals to add such features.
Right, I see. What parts of your open-source contributions would you want to remain private?
The ones that are not open source. Assuming all code is open source is a little limiting. I mean people can choose to design their forges to accommodate only open source but it excludes a few use cases out there that might somewhat limit adoption. Not only open source projects might want to use federation.
Yeah, they seem to be mostly interested in open source for now.
They say they have plans for private repos but we'll see how that works.
... why would you want anything on your forge to be private?
I've considered setting up a private forge because I can't quite get the right auth model for my LLM agents on GitHub.
I want them to be able to read all my repos, and be able to raise PRs, but no commit/merge access.
I know how I could do that with my own private forge.
It’s great that people are working on federated forges. I myself a bit meh on ATProto and prefer ForgeFed. Not that I studied them extensively and can give a well reasoned explanation why, more of a gut filling. There are already a few small implementations out there. I can’t wait for Forgejo getting it implemented.
Wake me up when one can change their name in Fediverse… I think ActivityPub got some fundamental stuff wrong from the start, ATproto, while obviously not perfect either, got a lot right.
I'm pretty excited about Tangled, as it seems to aim for a pragmatic decentralised forge, also a lot of overlap on what stuff I like: Svelte, Nix, ATProto.
However reading the blog I also feel the same as reading some more in-depth ATProto stuff, that is, I have no idea what all these special terms mean when I try to put it all together. Appview, firehouse, knots, spindles, bobbins, lexicons; I nod along happily but at the end of it all I'm like: am I too dumb for this?
I'm trying to understand if I can selfhost UI + Index + Knot in Tailscale, as a completely private forge, only visible from within the tailnet.
I am not sure if the federated nature of Tangled makes this impossible. Any experience?