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
1) there’s an app-agnostic hosting layer (and anyone can run a host, a bit like personal site with RSS)
2) then there’s apps, which aggregate over data from all hosts (a bit like Google Reader or Feedly)
So there’s no such thing as “defederating”. You don’t have many copies of Tangled beefing with each other. It’s more like you can run your own hosting for your own data (if you want), and anyone can build an app that aggregates from everyone’s data (Tangled is one such app).
If this got you curious, I have two longreads: https://overreacted.io/open-social/ (conceptual) and https://overreacted.io/a-social-filesystem/ (diving into the data model).
Except that, crucially, RSS/Atom plays well with static nodes (e.g. personal websites generated with Jekyll/Hugo/whatever—or even written by hand[1]), and Atproto does not. (Nor does Mastodon; previously: <https://news.ycombinator.com/item?id=30862612>.)
It'd be great if the complexities needed to support the "Atmosphere" were widely recognized/acknowledged to be overkill and soon enough ended up going the way of things like CORBA and WSDL while in its place a resurgence of interest in the Atomsphere emerged.
1. <https://m15o.ichi.city/site/writing-atom-feed-manually.html>
Atom was designed for news, before social media existed, where 15+ minute polling times were (borderline) acceptable. Atproto was designed for social media, in an age of Twitter users getting their news in seconds, to the point of being able to comment on live events play-by-play. There's no coming back from that world.
With that said, I wish both Mastodon and Atproto supported opt-in pull-based, static sources.
And this is widely recognized by now to have been a very bad thing, even/especially those most susceptible to its draw. It's strange that you're framing it as a strength and not a lament.
> There's no coming back from that world.
You can't say that when everyone just begs the question and shoves application-server-needed-here protocol designs to the fore.
It has upsides and downsides. The ability to live-post an event, or get up-to-the-minute news, can be a good thing.
Atproto's PDS is the root idea that everything extends off of, is the "social filesystem" that you control. There's a protocol objective to be able to spread your data around widely and for folks to be able to cryptographically check that that data came from you (even if you have to change hosts or even if someone sneakernets your data around). That's going to have some complexity! But it allows aggregation, is essential to how we are able to syndicate data so widely in atproto. It's so important it's in the name: Authenticated Transfer protocol.
And that in turn enables systems like Tangled here to be built, that layer stop the personal data servers, and relays. These work because there is identity.
If you need your static site to be on atproto (yay!), you can just have one of the various PDS hosts (such as Bluesky or eurosky or black sky or npmx) host the PDS for your. Since it is authenticated and user sovereign, you can permissionlessly move to a different host whenever you please, should that go awry. It's unclear to me why static site needs are an interesting or useful target that social networking ought conform to.
If you want to make a simpler network where we don't have those guarantees, please go right ahead. It feels to me like a snap reaction though that doesn't bother weighing what we have gotten or why things are this way, that is reflexively demanding.
These seems to defeat the purpose of the relative amount of sovereignty that hosting a static site gives you compared to depending on a PDS.
> It's unclear to me why static site needs are an interesting or useful target that social networking ought conform to.
How is this possible?
Your lack of a reply at the end, refusing to support basically your entire ask with even a modicum of supporting cause, feels a bit vindicating, that indeed you are a hostile agent & not here to engage or discuss, but to throw bombs.
Have we met?
Unless they gut or disable their API, and then ban scrapers, although I understand why after seeing bots crush sites.
Also, tangled is atproto based, the big blue mothership will always be in control.
Your account is hosted on a PDS and you sign into the app with your PDS sign-in and records go to your PDS, but everything on the app is from what's called an "AppView" which provides a centralized view of all data in all PDSes so it feels just like you're using a regular centralized app. But there can be multiple AppViews and AppViews can be self-hosted.
So unlike with Mastodon, it doesn't matter what PDS "instance" you're on because the app layer is completely separate from it.
Regardless of name and precise technical details, there are central service components that can ban you. If a proper ecosystem of those ever springs up then the equivalent of fediblock (ie guilt by association) oriented at individual accounts or PDS is the next logical step. At present (last I checked) there's only (approximately) one primary provider plus blacksky making the situation even worse.
This isn't some wild hypothetical - we also see guilt by association in the matrix ecosystem.
Most bans today are at the "appview" level: the big indexed view of all the data, that combines the firehoses ("relays") marks accounts as banned & doesn't show their stuff. But the relay and the PDS still work.
Agreed that there aren't many public appviews for Bluesky posting right now, really just the two. Tangled itself though is an appview, of a different sort: one not for posting but for git issues/pr's/rtc. This appview isnt gated on Bluesky or Blacksky's permission. And folks could pretty comfortably host Tangled aplview themselves, subscribing their Tangled instance to any of the dozens of firehose/relay instances, getting all pre-filtered Tangled activity. And that really is quite decentralized a model that is imminently doable. Regarding the technical properly, the concern here about banning feels premature & naive: it assumes Tangled depends on these appviews at all, and it doesn't.
I will note that Phil's constellation project just tackles the key reverse indexing that comprises much of the appview work: taking all the firehose records, and connecting all the threads and likes together. Constellation runs ok as a public service on an rpi. There's a lot of challenges to making new appviews, but it is astounding and comforting seeing the core indexing for a sizable multi-media social network running on an rpi. What seems like a dire situation may actually be opportunity, if folks actually tried.
Whatever problems we want to foresee dooming us, whatever slopes we want to hypothesize sliding down, what we have here sounds way way better than anything else available to me today. Personally I'm much more bright blue sky sunnier about the prospects rather than your dark raincloud doom fall scare-away. The risk imo is immensely more weighted in not trying more than trying.
The key difference is that ATProto currently only has a small handful of instances, ie it remains largely centralized. Certainly it's a blessing that the operators appear to have generally acted with benevolence to date but that's not really relevant to the point I'm making.
Resulting in everyone just picking the "default" instance.
You say this as if it happens often, but it's more likely that a smaller instance will go under because of costs, and there are tons of perfectly fine instances where this doesn't happen at all.
Also you can join more than one instance.
Also it costs very little to host your own instance.
This is not a problem that exists for most people using Mastodon.
I agree the onboarding process is a bit confusing but really it isn't much more confusing than subscribing to a subreddit, except your identity only exists on that subreddit rather than a separate account.
Which I would definitely agree is a flaw but not an insurmountable obstacle.
I'm conflicted about the costs of what is currently effectively global discovery, but it's not just another Mastodon.
E: I think its funny multiple other people said the same thing in the time it took me to write this
These days running a relay is fairly cheap (~$30/mo?), there’s maybe a dozen of them, and some apps don’t use one at all (instead relying on services like https://constellation.microcosm.blue/ for querying backlinks).
Comparing open source social to algorithmically based social is never going to work, that's like saying the Light Phone isn't as popular as the iPhone, so its a failure.
The question is, does it work for you ? If over time open social gets a toehold then it will be an option people know about and can choose.
Why do you have to take a side / take the correct side? Can't you either just not take any side or take whatever side you feel like and go with that?
Of course, all sides are wrong in somebody's eyes; so no matter what you do, you will be defederated from by at least somebody.
The way Mastodon works, defederation irreversibly breaks all follow relationships, without notifying those involved. If you disagree with the decision, you can migrate to another server, but you won't get your followers / followees back, not without everybody involved doing a lot of manual drudge work. This is just one way in which the myth of "users are free to do what they wish, if they disagree with the admins, they can migrate somewhere else" breaks.
To make matters worse, there's no way to see which users that you may wish to follow are / will be hidden from you if you choose a given instance. Defederation lists are a (somewhat open) secret; it's good practice to announce defederations, but there's no automated API endpoint to see them, so there's no way to answer the question of "who am I going to lose if I migrate from x to y."
Ok, so? People block you all the time because they don't agree with you, why is that a problem? If people don't want to hear what you say, shouldn't they be allowed to not listen?
Personally, I don't understand that point of view of blocking people who you disagree with, for me the point of the internet is to find different views and perspectives, but I'm also fine with others filtering out whatever I say, doesn't really impact me either way.
If you want no rules what you say, run your own instance. Depending on what you say, some people will want to listen, others will want to filter your opinion away, I don't think either sides are "wrong" for that, it's just like in real life. If you want to use someone else's instance, you follow their rules. It mostly isn't harder than this.
You go on a cruise for two weeks and there's a disagreement about whether to federate with Meta or not. Your admin takes a side, whatever that side might be. Two weeks later, you come back and lose 10% of followers, and there's nothing you can do about it.
Nobody chooses instances for that, very few know anything about the admin, people just like the content until... in >70% of cases, bait and switch follows
That's why Mastodon is such an incredible mess, it creates the conditions for serious problems, then goes: "you chose what you knew nothing about, nor there's any way to know anything, therefore... you are the problem".
Ahckchually, once you create an account you can use the API endpoint for remote lookup to test in an automated manner which nodes are and aren't reachable.
Yes, it's that toxic. Go subscribe #FediBlock hashtag if you don't believe me.
I've seen that, and I'm not sure what's supposed to be toxic. It's community-organized filtering of unwanted views, for the people who want to engage in that. I don't agree with that, so I don't participate or do that myself, and I also don't seem to face any negative consequences because I'm not participating in that. What am I supposed to be sad about here, that some people don't want to listen to my views?
> sounds like people you probably don't want to interact with anyways?
That's all well and good when it's a single user instance or small group of friends. But often enough it will be a much larger one with unknowing participants caught up in it. Blaming them for choosing the "wrong" instance is about as productive as blaming people for using facebook - technically correct but that's about it.
That said, the AP model seems like the least worst to me. Every option I'm aware of has significant downsides.
Again, go check #FediBlock. If you'd like a specific example of the single issue vs multiple issues, pay specific attention to trans vs black conflict there and see how it is played by both sides.
The problem is when this is a large server with people you know using it. They suddenly disappear from your feed. And those people may not have even agreed with the reason for defederation.
At that point, the only way to connect with your friend(s) is for you or them to find new servers that haven't (yet) gotten into a defederation slap fight.
The TL;DR of the problem with Mastodon is that you basically need to pin your identity to what is essentially a small internet community/forum and then give them full power to decide who/what you can consume while your identity is tagged to their community.
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.
And it does seem to have the right feature set. Not sure which other social graph/network you could reasonably build a GitHub alternative around that would be less irrelevant....
Obviously Tangled can live completely separate from Bluesky, it doesn't even need to share branding. Protocols are just protocols and people who don't understand how email works often don't even realize that Outlook and GMail use the same protocols. I'm hoping for this future personally where ATProto is only something the nerds care about (and write code for.)
(Please don't respond to this post with ideological argument. I'm just trying to talk about Bluesky and ATProto.)
That may be the case, but anyone can use ATProto. Unlike X where reach is suppressed for ideological motivations, or Mastodon with the federation turf wars, anyone can use it, regardless of their politics. If you disagree with the ideology of the majority users and avoid it for that reason, it just perpetuates the problem.
Unfortunately, I suspect it is only that way at present because the "other side" is perfectly content to continue existing in a communications environment that prioritizes them, rather than one that is actually open.
One example is if you don't care anything about atproto, you can create a new account on Tangled's website that creates the account on their servers, but thanks to how atproto works it's just like you made one on Bluesky and can still interact with Tangled and everyone on the protocol for it's social features.
Pretty unclear what your comment is trying to indicate but it sure feels very different to me, and I've offered some characterizations for why.
More generally, atproto is useful for all kinds of tech, solves a cold start social network problem. Aren't we reinventing forums, and tv watching, and book reviews, and trail maps, and photo sharing, and streaming, and d&d, and key attestation, and file sharing, and publishing, and note taking and containers and git hosting? Yes. Yes we are. https://atstore.fyi
(Under a common protocol set, in a way that respects users unlike everything else that's happened online so far.)
What you are calling "negativity" are genuine concerns to me. I was excited at the headline first. But as soon as I found it is VC-funded, it became a complete non-starter for me.
Look, I'm going to make my labor of love available to the world on your platform. I'm not going to earn a dime from it. It's just free work I'm gonna put out there. If I'm going to do that, I'll choose a platform where I can be reasonably sure that there won't be a rug pull 5 years down the line.
The problem with VC-funded projects is that there is definitely going to be some kind of rug-pull. Because the investors need their money.
The Git hosting services I use today are those where I can pay as a paying customer or I can pay as a paying member. As a paying customer, I know what I am getting into. As a paying member, I have the right to vote on decisions that affect the platform.
> The problem with VC-funded projects is that there is definitely going to be some kind of rug-pull. Because the investors need their money.
If you can tell me up front what the rug-pull will be in N years, then I could potentially look past it for certain use cases.
But if all you say is "I know you don't like VC-funded companies, but ours really is different because of X" then that's pretty much a slap in the face to users who've been through the hamster wheel of enshittification before.
I don't really like services that stress how idealistic they are when this is the upcoming reality.
Better charge money for services or if you're truly idealistic start it as a non-profit. At the very least communicate what's the monetization plan.
A protocol isn't a good enough reason for investors not getting their payday. They'll just force aggressive and reckless changes to see a return.
The only way this kind of thing works is if profit isn't in the equation, or the easiest path to profit lines up with what's best for the customers.
This is why I'm skeptical about bluesky in general. Despite the protocol, it's incredibly centralised. If they wanted to make money it won't be long before they start putting up the walls around their garden. The same thing applied here as well, if investors demand a return the open protocol usage will shrink or become less open.
What points towards bootstraping being impossible? Sure, it's difficult, that's almost in the name so makes sense, but impossible? Especially if you're aiming for the federation-angle, then you should be able to build cheaper infrastructure, not the same/more expensive.
Even just the security concerns and having any confidence in the implementation is likely a specialized skill, so you'll need to convince someone to work for free or be able to pay them. Now do that for other major lines of work like UI/UX, Ops, and QA.
Take a look at all of the features from GitHub or any code platform that you'd need to get people to sign up these days (because they are used to GitHub/others) and it's a very tall list. Think something like https://www.enterpriseready.io/ but definitely larger (maybe 2x, 3x as large).
Oh and if someone writes a long rant about it and it gets to the top here, it likely becomes dead in the water, and you can't get the time back, making it a risky proposition. At least with VC money, you got paid a salary.
The aim doesn't have to be "Be the next GitHub", but something else, and that's just as valid and "successful" as anything else, as long as they survive as communities.
It’s a bit long but should give you a really crisp picture.
Fossil gets 90% there with integrating tickets (issues), forums and wikis as part of the repo itself. When you clone a fossil repo, those are also part of the clone, and can be browsed offline on an airplane. Replies can also be written offline and, permissions willing, synced back up to the remote, either immediately or when the internet connection is regained.
I think this is the direction we should go in, but without hardcoding any specific artifact kind as part of the VCS. Instead, repos should be able to contain apps, which would define policies on what artifacts are acceptable, what rules they must follow, and who's allowed to upload and download them and at what times. The job of the forge would then be to execute those policies and render the artifacts for web users in whatever way the app desires.
With such a setup, moving to a different forge would entail nothing more than pushing the repo there.
This is going to be so nice.
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)
I mean, practically no one is aware of any other ATPROTO provider other than Bluesky whereas the issue with AP is merely the lack of better implementations, so mastodon.social got the most attention and the hype died off with niche success.
In atproto, there’s two axes.
One is hosting. Bluesky offers hosting but some people host on their own (it’s just a Docker container with sqlite), some on Cloudflare, some on community-hosted nodes like https://npmx.dev and https://selfhosted.social. From app perspective it looks exactly the same way (unlike in Mastodon where “hosting” = “choosing a community”) and you can switch hosting anytime.
Another axis is apps. Apps aggregate from data from all hosts. Bluesky is an app, Tangled is an app, Leaflet is an app, Wisp is an app, Semble is an app, and so on. Those can all aggregate over the same data (which enables cross-app interop) but they don’t have to (eg Bluesky doesn’t overlap with Tangled much except that Tangled can reuse Bluesky avatar on login). Generally you don’t have people running copies of the same app (as in Mastodon) which is why there aren’t many “blueskyes”. But when someone has an incentive, they can. (Eg Blacksky is a complete fork including server and DB, allowing their own moderation decisions over same data.) Similarly you can build your own app on top of distributed Tangled data.
Hope that helps clarify why “atproto provider” as a concept doesn’t make sense. You have hosting, which is as distributed as you want, and you have apps, which anyone can make.
And if the answer is "yes" then at least when someone "makes their own app" can they easily use "Bluesky hosts list" + add special extra hosts (or remove specific hosts) so that the app relies on the platform, with the exception the disagreement point?
An app can choose to ignore/ban some users (or even entire hosting servers if they’re specifically created for network abuse). This is similar to how any web app may choose to ignore POST requests from spammers.
And yes, someone can decide to aggregate data themselves and provide an alternative app over same data with different moderation policies. In fact that’s already the case (Blacksky runs their own application server that mostly piggybacks on Bluesky moderation decisions but overrides some of them. There are also clients that ignore moderation altogether and show you the raw data from hosting.)
Domain here referred to the area of influence or control, like what the provider of a relay effectively has. The fact that other groups can run any element of the infra themselves doesn't change the fact that the drift towards centralization is much greater with ATP than with AP.
ATP has its own uses (quick aggregation) but it doesn't even attempt to solve fundamental issues of current ecosystem of social networking,. AP, on the other hand, offers the foundation for further development in the right direction.
Hosting providers don’t need to discover other hosting providers. Data only flows between hosting and apps; not between hosting and hosting or apps and apps.
We already have other decently sized GH alternatives such as Gitlab, Codeberg and various OSS forge instances (freedesktop, Fedora, Debian, etc) which could be federated and become a safe harbor if we were able to maintained project visibility and discoverability.
But I saw this project a few days ago and thought to myself "Hey, this one could actually work." The difference here is that the target audience has a pretty strong overlap with the part of society comfortable with self hosting services.
I don't need my whole network for this one to be useful, only that subset that's actually most likely to show up.
The server costs for the frontend should be very low allowing them to operate basically forever and they are fed in by a series of other hosts
Tangled here is a great example. An existing user base of a social network was able to rapidly join and start using a new app, a git forge, to share repos and collaborate. PRs and comments show up like any other record on the network.
As for how the network works: atproto tackles the cold start problem by layering architectural concerns. Each person is their own server ("personal data server" aka PDS). But aggregation layers ("relays") collect all PDS activity they can find and relay it to consumers. Then applications such as Bluesky or Tangled ("appviews") can be built by reading records of interest (of the right "lexicon" type) from the relays. Each person owns their data, relays make all data available, appviews distill out user experiences appropriate to the records they cover.
Even though it's federated, when development stops, who will be there to fix bugs and maintain it?
VC money is a means to an end. We're both Indian founders in Europe, and grants are nigh on impossible to find (4–12+ months for anything to materialize). VC is quite simply the quickest way for us to build a team, setup infra and accelerate development. We're also incredibly aligned with our investors on our goals (we took 6+ months to find the perfect partner for this).
While I was quite excited about some of the ideas being discussed in this project, it being VC backed is a complete non starter for me. Your claims of being built in the open don’t make me feel any better, you will eventually need to make returns for investors.
But now you need to grow fast, which greatly increases the risk for me as your potential user, so you should at the very least write a post to make sure you're aligned with your users not just with your angels.
How are you going to use the money? What's the business model? How do you ensure you're around in 10+ years? How are you going to please your overlords with that business model and what will you do if they force you to squeeze more money out of the business?
I hope you succeed, because the competition is good for users, but VC-founding is a liability not a strength.
I prefer slow and steady wins the race kind of project. Good luck!
I'm with the OP you're replying to. Taking VC is an albatross that means a large portion of devs will never trust you or use your services (outside of bleeding your funds dry).
If this place truly cared about community they should have made a non-profit or some type of NGO, basically anything with a true community governance model. Not the current model of caring about money over a community.
We currently live in a society that solely cares about money and seriously doubt devs want to continue uplifting the current system that only benefits the rich at the expense of everyone else.
How many board seats does the company plan on giving to the community to ensure enshittification doesn't occur?
Do you want software to become as closed source as mechanical engineering? No! So let's celebrate people building software that's open source, even if it's VC funded! They are awesome for doing that!
Come on.
As a user who would need to invest time and effort in using Tangled, I think it's fair to ask to have the plan explained. I'd rather see explicit price for services than see enshittification happen.
We should celebrate people building open source stuff and in the public. The alternative is for the software tooling ecosystem to look like EE or mechanical engineering tools - all closed source, proprietary, and with super expensive licensing.
It's easy to take open source for granted - 'information wants to be free', but we are at risk of the open source movement dying with proprietary AI completely changing everything about software.
If we penalize people who are working toward the right goal, we contribute to that decline.
The two reasons actual communities work in actual locations are: 1) because to some extent the people all live in a place and want the place to be nice for them and their (grand)children, so they are invested personally and 2) companies aren't set up to help communities. Communities are the ones doing community things. It's crazy to demand other people do work in a certain way when you're doing nothing.
There are plenty of examples of VC funded companies that care about community & don't "only care about profit". Bluesky is a good one (literally a community / social platform). That's such a black & white take it baffles me.
> Taking VC is an albatross that means a large portion of devs will never trust you or use your services
A "large portion of devs" (the majority) use so many VC funded services? Probably _most_ services devs use are VC funded. GitHub itself - was VC funded.
You can have an anti-VC opinion but you have to also live in reality.
GitHub was founded in a very different world. Would we start using it today is the question.
OpenAI and Claude both took VC money and everyone on this message board uses them regardless of ~community~
Not all VCs are scum
Those of us who use it. Tangled is a neat project and architecturally it makes a lot of interesting choices but code-wise it's relatively simple and from my personal forays in it I'd say pretty easy to maintain.
The majority of the codebase is loosely related go modules. Then some static HTML+CSS. And finally a small sprinkle of typescript to tie things together. And of course a bit of Nix for orchestration.
IIRC it all runs on a pretty trivial amount of hardware that a single person could currently host by themself.
Users' knots, spindles, and PDS (plus atproto at large) do the real heavy lifting infra-wise.
At least this statement doesn't hold for LibreOffice. Their Online version, including "simple" HTML/CSS components, was archived because of a lack of maintainers. For their main project, the vast majority of contributions in the last release were made by former ecosystem partners (Collabora) or TDF staff. Volunteers only did a fraction of the work [1].
[1]: https://www.collaboraonline.com/wp-content/uploads/2026/02/L...
Why does it need VCs? Why not company and corporate sponsorship like Ladybird?
Why should we spend our time on a developer tool that would be enshittified down the line when VCs expect 10x returns?
So even if they don't expect returns from a given atproto project, they are investing money (and therefore funding FTEs) in the ecosystem at large.
The investment isn't necessarily in any one of these projects in isolation. It's in the AT protocol at large.
You talk about corporate sponsorship like that's trivial to find. Trust me when I say we spent over half a year chasing down grants/sponsorships only to be met with closed doors, extremely long wait times for pennies. We'd also be required to keep our day jobs—which means less focus on Tangled dev, and ultimately very slow progress overall.
We debated VC heavily (we're both idealists after all), but figured we can make it work—it's ultimately the founders that make bad calls leading to enshittification. There's plenty of examples of VC-backed companies that haven't enshittified. Tailscale is an excellent one, and hence we brought on Avery as an angel in our round.
Perhaps maybe in a few years time, Tangled Enterprise would be available to compete with GitHub Enterprise and that is where the switch over happens for companies who want to move over from GitHub to Tangled.
I don’t know because somehow Tangled would need to make money somehow?
I hope Tangled becomes profitable enough to withstand enshittification, because more and more funding rounds and not meeting targets means giving up control and facing a repeat of what happened at Bluesky.
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.
ActivityPub is email-shaped. Servers are inboxes sending messages to each other.
atproto is web-shaped. User repositories host data (like personal sites or git/RSS), while apps aggregate from repositories (like Google Reader).
Different topologies lead to different properties. Eg atproto lets user change hosting with no disruption in app experience. atproto also lets anyone build new apps aggregating over existing data.
ActivityPub doesn’t allow either of those things. It’s literally a bunch of small centralized coupled hosting+app services messaging each other.
Proper federation is exactly such bunch of small services messaging each other. On the hand, what ATProto leads to is at most a handful of large-scale providers each running the own portion of the network.
1) a layer of app-agnostic hosting providers + a separate independent layer of apps aggregating over data from those (like personal sites with RSS + aggregators like Google Reader)
2) a circle of flat instances where each node couples app+hosting (like many little Twitters)
One doesn’t couple hosting with apps, another one does.
Mastodon/AP model is (2), atproto model is (1). You should be able to see the outcomes from different network shapes.
In atproto, you can build a new app that works with existing data, but in AP you can’t. In atproto you can move hosting with zero effect on your identity or how you show up in apps, in AP you can’t.
AP isn't completely stagnant but there's a reason AT is still holding on to and accelerating that early developer excitement AP had. Maybe it's marketing, maybe it's money, maybe it's some technical thing. Maybe it's the community. Whatever it is, people seem to enjoy developing in the Atmosphere in a way I never saw on AP.
(as I understand it) the data has to live in a PDS, PDS are keyed by accounts, so you are similarly stymied for collaborative projects? I guess AT Proto is still a real work in progress so maybe that story has improved since the last time I checked it out.
this is the key bit, atproto has this. sidecar services like knot can use service authentication[0] for authenticated requests.
https://dholms.leaflet.pub/3meluqcwky22a
https://dholms.leaflet.pub/3mfrsbcn2gk2a
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.
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.
> Please be aware that GitHub and GitLab are exceptions to this Policy because they are subject to explicit licensing arrangements that pre-date, and thus take precedence, over this Policy.
GIT is a trademark of Software Freedom Conservancy and our use of “gitea” is under license.
