icy

to be honest, i thought this would be links to threads frequently mentioned on hn, which would be actually kind of useful

I think you fundamentally misunderstand how the protocol works.

First, Tangled has been entirely self-hostable since the beginning! We've just made it much easier to run for everyone.

Second, the "appview" is simply an indexer. It consumes records from the firehose and only those that it cares about. In our case, those are org.tangled.*. There's no reason we'd consume all of the firehose.

ActivityPub categorically does not make sense here because of how coupled identities are to instances.

We will in the next couple weeks!

Indeed. Repos own issues and pulls now! We will publish a post on how we do this very soon (hint: we store them as git objects within the repository and project them as an AT Protocol MST -- hence making knots PDS-like).

We already do.

> I suppose in the long run we really shouldn't be assuming that code storage is just Always There or easily cached somewhere, but I anticipate some growing pains in the mean time.

Pretty much. We want to make running your own git remotes as easy as possible. Lets you scale on your own too.

> ATProto doesn't seem to have the benefit ActivityPub has where if the instance I wanted to view content on was down I can usually find some other instance that's gotten the messages.

It does give you (or anybody) the ability to index this data independently, and not miss messages -- which AP doesn't afford. Different tradeoffs!

That's exactly the problem we want to solve. Of course, they still need identity of some kind -- in this case, they'll need an AT Protocol account -- either by self-hosting a Personal Data Server[0], or signing up with a provider such as Tangled or Bluesky/Blacksky, etc. This is the last ever account they'll need (and it's theirs, and portable!). They can then begin contributing; they'll use this same account for all of Tangled and other AT Protocol services.

Your Tangled git server that you'd want to run is a 'knot'[1]. It's not exactly analogous to Forgejo because it's headless, but that makes it super light on resources to run.

[0]: https://atproto.com/guides/the-at-stack#pds [1]: https://tangled.org/docs/knots/self-hosting/

Hi! Tangled co-founder here. We're super stoked with this launch -- we've stabilized our AT Protocol lexicons, completely overhauled our architecture and UI, and made self-hosting the entire stack (or parts of it!) incredibly easy. We've also shipped support for organizations, and have private repos rolling out in the following couple weeks.

Happy to answer any questions at all.

The article, while interesting, is clearly Claudeslop.

Bluesky?

> tangled will struggle to have private repos that align with user expectations for RBAC, atproto ACL permission proposal is insufficient, Bluesky is not interested in alternative proposals, the centralization of atproto is most prominant in who has write permissions to the repos

This isn't entirely true because we're working on our own extensions to the protocol that will enable full-fledged RBAC at a knot/repo level. We're not beholden to PBC and AT Protocol; when needed, we're OK to roll custom bits.

Great! Then we've got a hosted solution at tangled.org. :)

> Tangled is forcing some of their particular technologies (nix/rust) on users for those pieces and that is a hard sell. I don't use those techs, so I'm not interested to use a platform that I need to learn them to use.

Tangled CEO here. How are we pushing Rust exactly? :D Nix, yes but you don't really need to touch it at all with our Alpine-based CI images.

We have been under heavy load the past day or so, we're working round the clock to scale!

Forgejo federation being mentioned each time never stops being silly. It hasn't been a thing for years, and they don't appear to have made any meaningful progress to show for.

We don't yet support private repos, correct. This is very high priority on our roadmap (~6-8wks out).

Of course, just head to tangled.org/timeline :)

Yes, it's on the roadmap.

We already support JJ for stacked PRs, but more native integration is planned.

https://blog.tangled.org/stacking

The neat thing about Tangled is you can build your own frontend pretty quickly. We've got an open API https://api.tangled.org (or self-host your own API server: https://docs.tangled.org/bobbin#bobbin)

It's not crypto anything.

https://tangled.org! Founder/CEO here. We're a new forge building things from the ground up, and are fully federated -- you can host your git repos on your own infra, along with the CI runners. We've also got a pretty neat set of features (if I may say so myself): stacked PRs, Nix-based CI (if you want it), and a fully open protocol (https://atproto.com) to for you and your agents.

Happy to answer any questions.

https://tangled.org would love to have you :) We're hosted in the EU, and are free for open source, forever. Tangled is also designed to be federated from ground up, so you get to own your infra & data while still participating in an open network.

It initially begun as an email thread, but we settled on WhatsApp owing to, well, most people having WhatsApp.

Thanks for reminding me to attend this. I'll try to join the next one!

I mean, it's an sqlite file on disk. You can sync it however you like. https://litestream.io is a fun choice.

We’re solving for this very issue. Issues & pulls will belong to the repo, backed by a “COB” (collaborative object) system.

Tangled is built for jj :) We support stacking using jj change ids: https://blog.tangled.org/stacking

That's Tangled! Self-host your knots, AT Protocol for identities, and an "indexer" at tangled.org (easily replaced).