I don't think you understood. You can still get a feature complete social experience that is NOT ISOLATED from anyone.
Your GitHub Enterprise comparison is wrong, because with an onprem github entreprise you don't have the social github features (and that's the whole point of tangled, use something else if you want a private forge for your company, it's not for this purpose)
My point is, Tangled being on ATProto, you can still access all of the repos, PRs and issues of other people by looking through your self-hosted appview even if the official appview is down, because an appview, is just that, an "app *view*" It's the view layer in your traditional app, and ATProto is the database.
It's a view of the data on the ATProto network, it is not the data holder, everyone can be their own data holder that is visible through any appview.
> downtime and self-hosting is not a reason most people are convinced to move forges, it takes a lot to get someone there
Yes, I agree, but I personally think tangled is great because of the interoperability
People on codeberg, on gitlab, on github, on self-hosted gitea instances, on self hosted gitlab instances, and so on, all control their issues, PRs, and git repos (they run on their own infra) but they are also more independent, are not subject to a central platform's policies (or are subject to the one they prefer) and so on, and they also introduce contributor friction, you need separate accounts, it can be difficult to cross reference issues and PRs accross projects on different forges, users can't easily have a central feed of project they starred.
On tangled you get to have the first part (freedom) while not having the second downside (unique account, cross-references work seamlessly, etc...)
Give me reasons open source projects moved forges away from github, and I am pretty sure if tangled did exist when they did so it would fit more boxes of "why they left" than their target forge.
atproto is not the next thing, there will be more social protocols to come
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
While private repos are usefull, I do not think that is tangled's main proposal at all.
I am just thinking you do not like tangled because you don't use the social features of github and so don't see the point here. I can understand that, but then tangled is just not for you ?
And yeah ATProto is not the next thing, but IMO having a portable identity and services that can act as "one big single app" are requirements for a modern social protocol to do applications like Twitter,Instagram, and github's social features for example, ATProto is just the one that does it better imo for now.
But again since you are always bringing on private repos, I think tangled is just not for you since the ATProto model is for open data and so fits open source projects really nicely I think.
> I am just thinking you ...
you are incorrect and this is why it's advised not to project the answer but ask a question instead
for clarity, I do in fact use github's social features
I also believe that the idea around the atmosphere that the point of atproto is to have open data is completely misaligned with how most of society wants their data handled, this is based on my talking to people IRL, outside of the echo chambers of social media, what's actually happening is more and more people signing off because of toxicity
open source and small devs do not pay the bills, github is financially sustainable because they have enterprise clients, same for gitlab and bitbucket
> 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.
> we're working on our own extensions to the protocol
what I hear is another path to app centralization, regardless of your intent, this is what comes out of custom extensions to a protocol
bluesky should have actually been open about the permissioned design process, posting your own proposal to a blog and not entertaining other proposals, or even joining the broader conversation that was happening, is not open in my book