Really looking forward to seeing Tangled develop! I've got a side project that's main repo and CI is on my self-hosted Gitea but code and releases are mirrored to Github; I'm hoping to move it off Gitea and onto Tangled for code/releases/potentially CI and just keep Github for discoverability/backups/namespace "squatting".
Just need git-bug to add a Tangled bridge so I can keep issues synced and (ideally) for there to be instructions for running the client self-hosted. It doesn't have to be a full featured client but I also don't want to be SOL for web visibility if the main Tangled appview is down.
One musing: I did run into my first "issue" with federated Git hosting the other day while setting up Neovim on a new machine. One of the plugins I use is hosted on Tangled and I guess its backing Knot was down. This was awkward for two reasons:
1. It as unclear to me from the Tangled website the backing knot was the issue (for a while I thought it was something on my end)
2. I really had no backup plans for something like a Neovim plugin's source forge being down and, clearly, neither did the Neovim package manager as it just kept showing an error on every session I started with no way to fix it :).
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. 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.
icy 2 days ago [-]
> 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!
embedding-shape 2 days ago [-]
> It does give you (or anybody) the ability to index this data independently, and not miss messages -- which AP doesn't afford. Different tradeoffs!
Someone (or some group) could also in theory go fully content-addressing with their data store, and make content available based on their hash, effectively layering that missing benefit on top of the existing architecture. Someone could probably vibecode this together in some hour(s) :)
I do agree that the sweet spot in federated git hosting could be a system merging the features of tangled with the features of radicle
But I have to admit that the design tradeoffs are really different
nerdypepper 2 days ago [-]
> I really had no backup plans for something like a Neovim plugin's source forge being down
this problem could exist with any package manager, the go package manager is one example, where it allows specifying packages from any git url. we host a mirror of all git repositories on our infra, and serve that when the backing knot is down. you could choose to trust that and pull from there (verifying that the tarball has a known correct hash), the way the go package manager pulls from proxy.golang.org.
stryan 1 days ago [-]
Ah, I didn't realize the tarballs on the Tangled site were cached. If it happens again I'll try that :)
But yeah I recognize it's an issue for any package manager. I suppose I just forgot that even something like my local editor is reliant on remote forges now unless I go out of my way to mirror it all.
spockz 15 hours ago [-]
Is it an issue for every package manager? In theory, yes, in practice no. Debian and arch etc have so many mirrors that it isn’t an issue.
packetlost 23 hours ago [-]
I started mirroring as much of the core git repos I depend on to my NAS with systemd timers to update from remote, and post-receive hooks to mirror externally if I control the repo. This reminds me that I should expand those efforts
malte_querier 23 hours ago [-]
[flagged]
icy 2 days ago [-]
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.
kstrauser 2 days ago [-]
I’m excited about this direction. I’ve moved most of my own projects onto my own Forgejo, but miss it being easy for remote strangers to open PRs and such without registering in my system, which I have zero desire to allow.
So what’s the state of Tangled today? Say I have a Tangled server (instance? host?) up and running with my repos. Some stranger wants to contribute. What do they have to do before they can open issues or send PRs or whatever?
icy 2 days ago [-]
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.
Got it. I'm still trying slightly unsuccessfully to wrap my head around this, but I've run a Mastodon instance for about 10 years and it took me a little while to wrap my head around that, too.
This is great. I'm delighted at the idea of having my own knot hosting my projects, talking to my friend's knot, and coordinating on a global project's knot, all without having to lock everyone into one centralized point of failure (even mine). Amazing. I love it!
nerdypepper 2 days ago [-]
all they would need is an atproto account. you can get one of these on Tangled itself, or bring your own. they can then open issues on your repository.
soon, repos will be able to declare a contribution policy: presently its open to all (anybody can open an issue), but owners can choose to limit this to just contributors for example.
kstrauser 2 days ago [-]
How soon will that be, do you suppose? It's not a blocker for most of my projects, but I can think of a few that I'd like to keep more closed (while still making them publicly cloneable). That doesn't keep me from using Tangled today for the open repos. It just means I'd need to have at least a couple of sharing setups - Tangled plus Forgejo - going at the same time for a while.
Also, will Tangled support private repos that are only visible or fetchable to specific people? Would that even make sense in its model?
nerdypepper 2 days ago [-]
for collaboration policies: its already part of the protocol, just needs to be baked into the flagship client!
private repos are coming very soon, we have a working demo of private repositories.
kstrauser 2 days ago [-]
Love it. Thanks!
rapnie 1 days ago [-]
Tangled looks great, and I may consider self-hosting a knot. But what I am curious about, and what I weigh in such decision, is what your business model is. Right now it isn't clear from the website, so I hope you are perhaps willing to share a bit on that here.
Are there any plans to add HTTPS clone/push support? For those who want to self-host their own Knots, an obvious approach is to put them behind Cloudflare. And being SSH only makes that complicated.
I wanted to try this but when I signed up for a BlueSky account it was immediately banned by some automation. I appealed but never heard back.
nerdypepper 2 days ago [-]
don't need to signup for bsky to try out Tangled however, you can directly just signup for an account with Tangled.
theptip 1 days ago [-]
Congrats on the release - private repos are going to be huge. How do you see the positioning vs Buzz and Radicle? Do you see them doing anything better now, and are you planning to try to close any specific gaps?
From my very limited testing private repos were the big missing piece; interested in other areas yet to be filled in.
0x457 2 days ago [-]
Are there plans to add http(s) support to knot? I was planning on hosting my own knot at home, but didn't want to expose my home IP (I use cloudflared for other services that need to be exposed)
nerdypepper 2 days ago [-]
already exists :)
its undocumented at the moment but you push over https as well.
I wish I knew this before I setup mirroring of my personal forge to github haha.
jauntywundrkind 1 days ago [-]
One of my biggest questions about the forged about is what kind of CI (and somewhat CD) do they offer?
What can I expect as a developer using Tangled to build (and deploy) my app? What is the native platform? What are typical other CI systems that have been adapted to work on Tangled (Dagger, Drone, whatnot, especially if there are repos to demonstrate the adaption)? What can I expect as enterprise or lone developer using Tangled or self-hosting or federation?
The system is called Spindle, but what about it? What does it take inspiration from, what are things like it that would help us spool up on this?
hauleth 1 days ago [-]
Tangled has its own CI named Spindle. However it is not limited to that as there is for example https://tangled.org/mitchellh.com/tack which allows connecting different CIs to Tangled.
embedding-shape 2 days ago [-]
> made self-hosting the entire stack (or parts of it!) incredibly easy
Back when you first launched, I thought running a knot was already pretty easy :) Could you expand on how it's different now, and what part(s) aren't now easy to self-host, if there is any?
nerdypepper 2 days ago [-]
self-hosting the appview was a bit trickier back then, but we have worked towards making that trivial. it now runs entirely in-memory, and is completely stateless (rebuilds the state of the network from scratch each time).
we have also stabilized lexicons, so if you are a selfhoster, you can expect to not require a breaking upgrade!
eterm 1 days ago [-]
I tried to run:
git clone https://tangled.org/tangled.org/core
And it failed?
Cloning into 'core'...
warning: redirecting to https://knot1.tangled.sh/did:plc:j5hmlfdrwkvtxm7cjmu7j2is/
remote: Thanks for using knot1.tangled.sh!
remote: Enumerating objects: 99191, done.
remote: Total 99191, done.
Receiving objects: 100% (99191/99191), 122.19 MiB | 39.12 MiB/s, done.
Resolving deltas: 100% (49286/49286), done.
error: invalid path 'localinfra/fixtures/blobs/did:plc:igzuueb63dytyy3tpaweofuu bafkreieify5bix4cmrj4iuxiceb6srr2boltkbbf7yizwtgwurqv42sltm'
fatal: unable to checkout working tree
warning: Clone succeeded, but checkout failed.
and retry with 'git restore --source=HEAD :/'
You can inspect what was checked out with 'git status'
It's not a great look when the very first thing I'd want to try to do:
1. Redirects from .org to .sh suspiciously
2. falls over.
I now have to try to work out whether that other domain is deliberate or compromised.
isityettime 1 days ago [-]
Afaict that's an issue with your operating system, not with tangled's git implementation. You're trying to check out a file with a colon in its name, and Windows can't handle that because of DOS baggage. If you mirrored that to GitHub or wherever and then tried to clone, you'd probably get the same error again.
Try cloning on WSL, in the VM's filesystem, and let us all know how that goes.
eterm 1 days ago [-]
Thanks, you've correctly identified the issue, although I wouldn't call it a problem with "my" OS unless it's my configuration.
I just wanted to read the source locally. I know things are getting worse by the month for developers on Windows because other developers are increasingly not giving a shit to support it, but it's odd to have a repo that doesn't even clone on windows.
Not building is common, not passing tests even if it builds is extremely common, but not even cloning is a new one.
I guess eventually I'll give up and switch to linux, but I'm still paid to work on Windows. I guess maybe it's finally time to look into a real dev-container setup for this kind of thing and I can do this all a bit more securely too.
ethin 1 days ago [-]
I feel that people still need to support Windows for a while. I for example am stuck on Windows because it (still) has the best accessibility out of all of the operating systems (and Wine is not a replacement for that). It's unfortunate, and I'm hoping it will change in the future.
willio58 23 hours ago [-]
I’m surprised to hear that, I don’t often use accessibility options on Mac but i use some on iOS so I always assumed Apple had the best a11y since there are so many options on iOS. Like almost too many, though I get that’s kind of the point.
ethin 5 hours ago [-]
Apple's accessibility is genuinely bad. As in, it's bad enough that Apple just doesn't bother fixing VoiceOver bugs at all, for years on end sometimes. Google isn't really much better. Linux is getting better but it's got a ways to go, sadly, and the accessibility isn't even remotely as consistent as Windows is, unfortunately. I wish I didn't have to use Windows, but Wine pretty much just got MSAA and doesn't have UIA, and neither translate to ATK/AT-SPI so Orca has no way of interacting with them.
isityettime 10 hours ago [-]
Most blind and visually impaired people use Windows. The options there are also terrible in lots of ways (resource hogging, apps crashing, general bugginess and lagginess), but the end user applications the (generally third-party) accessibility aoftware supports form a more complete catalog.
For my visual impairments, macOS is currently fine, because I only really need magnification and I can get away without using much of it since everything I really deal with is free flowing text, like in a terminal or IDE. But as I need to rely more on screen readers, I anticipate I may have to consider switching. Switching to something other than Linux would break my heart, though.
arjie 1 days ago [-]
The classic two FS errors I’ve seen are MacOS case insensitivity fusing two separate files and Windows reserved chars. Most people build and deploy to Linux so repos are usually sane to that OS. It’s just life though it’s funny to see the shoe on the other foot.
pessimizer 1 days ago [-]
If it's your configuration, it's not a problem with your OS, it's a problem with your configuration. Your problem is specifically that your OS has chosen not to support certain characters in filenames, and you want to write files containing those characters.
pie_flavor 1 days ago [-]
That's not a configuration. There is no way to configure Windows to accept files with colons in them. As well say it's a configuration issue if the software hardcodes the assumption of filesystem case-insensitivity.
isityettime 1 hours ago [-]
Agreed that it's not a configuration issue (and I think so does the person you're replying to), but interestingly this isn't a filesystem issue (unlike the case-sensitivity stuff). NTFS itself can handle colons in filenames just fine! It's just Windows that freaks out about it.
What's the business model here and how do they play to return the investment? It's aint easy to compete with GitHub...
sp4cec0wb0y 1 days ago [-]
Probably "org" only pricing tier like github.
IshKebab 1 days ago [-]
Especially if you don't support private repos at all... That's where the money is!
icy 1 days ago [-]
We will in the next couple weeks!
operator-name 1 days ago [-]
Cool! Will it be based on the spaces alpha?
bluerooibos 1 days ago [-]
I hope this takes off!
Some feedback:-
* I found the UI on the homepage/timeline a bit busy - lots going on. Notifications, Recents, Announcements don't seem like they need to live on this page?
* The Activity chart on a users profile page seems a bit wild to me. I'd suggest simplifying it or just using what GitHub/GitLab use with their square grid activity chart - it's what users are most familiar with. It's kind of analagous to all the LLM/Chat applications in recent years - they all converged on the same UI because that's what works - no need to reinvent the wheel when users understand an existing pattern. Plus - it's better for marketing:- people like to share their activity on GitHub/GitLab as it quickly conveys how much work they've done over the year - your current page doesn't.
pksunkara 2 days ago [-]
I see in the post that lexicon has been finalized. Does that include putting the issue, pr & comment records under the repo scope instead of the user scope?
I am asking because I have been waiting for that change. I intend to make all the public repos from https://juju.bi (code forge I am building) interoperable with Tangled and basically behave as knot server.
icy 2 days ago [-]
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).
Pre-update, code review UI was horrific compared to GitHub.
Post-update, code review is much better, but "Comments" section without a "Comment" button is unforgivable. People are probably closing PRs right and left without knowing it. Shift-Enter is a submit action.
I'm a keyboard-first user, but for something which can end up in somebody's inbox notifications, UI button is the way to go.
I just don't understand how such a prolific pattern is being ignored.
huksley 2 days ago [-]
Is the private repo support possible when self hosted?
jon-wood 2 days ago [-]
Not currently, Tangled's data model is entirely built around Atproto, which at least at the moment assumes everything posted is public. There's work in progress at the moment to layer access controlled data on top of that which I think Tangled could use with time though.
nerdypepper 2 days ago [-]
we have already got a working demo of private repositories that works very similarly to atproto spaces alpha, but without requiring spaces to be stabilized, we will have something to show off in the next couple weeks :)
donmcronald 1 days ago [-]
In the self hosting docs…
atcr.io/tangled.org/knot:2
Does anyone know if ‘tangled.org’ is verified / guaranteed to be owned by tangled.org?
max-privatevoid 2 days ago [-]
For a federated system they sure talk a lot about their struggles around scaling centralized infrastructure. ATProto seems like it's entirely the wrong protocol for this sort of application.
LelouBil 2 days ago [-]
ATProto is the right protocol for the social elements imo
verdverm 1 days ago [-]
Having worked on it for a while, I now disagree. The permission primitives should be baked in from the start rather than the bolted on after spaces because people continued to ask for these things and eventually Bluesky came around. There are many use cases for permissioned data and experiences that have to be built outside of the protocol, leading to fragmentation and loss of interoperability.
HexDecOctBin 1 days ago [-]
Ignoring the history, does spaces solves this problem or are permissions going to remain an issue? I was thinking of doing a project that is going to require a solid permissions system and was thinking of using ATProto.
verdverm 1 days ago [-]
Spaces left a number of core authorization building blocks out of the protocol. Those will need to be implemented in "user space" and I expect a number of different approaches will be attempted. I also expect this to become fragmented.
I shared my vision for what it could have been in the first ATProto Private Data WG: https://www.youtube.com/watch?v=oYKA85oZc8U&t=3812s (basically Zanzibar, UCANN is also interesting) I have ideas for a new protocol that would be permissioned, more federated, but still draw on the good parts of atproto. It's geared towards small social (think discord server / facebook groups) than big social (most common apps we think of - with reposts, quotes, blocks - features I have sworn off).
The Bluesky team didn't join the conversation until pretty late and then picked their own proposal (blog post series, was not formal at that point).
blackqueeriroh 1 days ago [-]
Here we go again…
verdverm 17 hours ago [-]
What do you mean? Do you have a substinative comment to add?
jauntywundrkind 1 days ago [-]
> For a federated system they sure talk a lot about their struggles around scaling centralized infrastructure. ATProto seems like it's entirely the wrong protocol for this sort of application.
Huh that's surprising to hear? What makes you think that? It feels like the whole point of this release is to make it easier to allow people to self host or federate whatever parts they want? That's what I got from their intro/opener!:
> But the centralised forge is crumbling. Relying on someone else for uptime, for features, and to be a good steward of your code hasn’t played out well. What has stood the test of time is email: Git to move the code, and email — an open protocol — to talk about it. At the cost of user experience, however.
> But the centralised forge is crumbling. Relying on someone else for uptime, for features, and to be a good steward of your code hasn’t played out well. What has stood the test of time is email: Git to move the code, and email — an open protocol — to talk about it. At the cost of user experience, however.
> Tangled aims to give you the best of both: the longevity of an open protocol, with the convenience and polish of a proper forge.
> It’s the first truly federated code forge — you can host code on your own servers and still collaborate seamlessly with others. Our approach is pragmatic: self-host just the parts you want, like Git hosting or CI runners, or all of it, including the API server and UI. Whatever you choose, you can still talk to everyone else.
The comment here from @icy emphasizes similar ability to let whomever host whatever parts of this they please:
> 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!)https://news.ycombinator.com/item?id=50306205
I don't see any mention of "their struggles around scaling centralized infrastructure". Is that just typical run of the mill low grade slander attack we see against atproto, more reflexive negativity? Or is there some actual interesting point here, that is perhaps even relevant to this tangled release?
max-privatevoid 1 days ago [-]
They had the mostly-centralized offering up immediately, and now they're spending a lot of time making the parts easier to self-host one by one. What does that say about the protocol? And I assume Tangled also suffers from the general ATProto AppView problem, where your AppView has to consume all the content in the entire network even though 99% of it is likely uninteresting to you.
Code hosting platforms are probably much more disjointed than microblogging platforms, so something like ActivityPub, where servers only keep track of content that users are actually interested in, would make much more sense. It's a shame that the people working on ForgeFed and/or Forgejo federation seemingly aren't making much progress.
icy 1 days ago [-]
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.
max-privatevoid 1 days ago [-]
> Tangled has been entirely self-hostable since the beginning!
As has BlueSky, as long as you had enough hardware to keep up with the firehose. The protocol heavily lends itself to centralization due to this design. I think this should be obvious by the fact that you haven't considered self-hosting to be the default case.
> In our case, those are org.tangled.*.
I suppose my wording was inaccurate, but this is what I meant by "the entire network". My indexer would have to consume "all of Tangled" instead of the things related to the repos, orgs and people I am interested in. Correct?
> ActivityPub categorically does not make sense here because of how coupled identities are to instances.
I feel like this is more of an inconvenience rather than a dealbreaker. Having to point people to a new account ID on the off-chance you lose your domain seems like much less of a problem than having to deal with ATProto's firehose architecture.
jauntywundrkind 1 days ago [-]
> As has BlueSky, as long as you had enough hardware to keep up with the firehose
We've already explained to you twice that this is incorrect, you don't need to do this. And that if you do want to do this for some ridiculous reason, just because, a $5 VPS can do it.
But you do acknowledge latter you are only talking about tangled records.
Currently very few people are worried about this problem, because all of the tangled traffic just isn't that big, and you can drop most of it very quickly with little impact. Relays do allow various kinds of filters though. You could use a service like Microcosm Constellation https://constellation.microcosm.blue/ that lets you find only records for your repos etc. That would work fine for finding the records pertinent to you!
No one does this right now, because the premise is faulty. There just really isn't any difficulty or cost of any note to having all the tangled records piped at you. Hopefully some day this gets worse, and that this becomes a good problem to have! One we already have tools (like constellation) to tackle.
In short: constellation is a (also easy to self host cheap light weight) service for reverse indexing, for finding records pertinent to you. Lots and lots of atproto apps use this for this kind of "find people making records about my stuff".
max-privatevoid 1 days ago [-]
> for some ridiculous reason
A ridiculous reason, such as being able to interact with the federated world from my own server directly, and not through a third-party service. Why is the simple concept of going to your own server to interact with the entire network, getting content directly from your friends' servers, and receiving interactions (e.g. PRs) directly from someone else's server such an afterthought in ATProto?
jauntywundrkind 1 days ago [-]
The relay exists because it means running your own PDS server is very easy and cheap to do.
You can host your own data very cheaply. If you don't have to serve every single other server, and keep them all up to date, and can just pump some records out at aggregating relays, it makes it much easier for people to be online. You can run a massive PDS on a tiny ancient rpi.
Which is what activitypub doesn't do. It's protocols are very heavy and hard and stateful. Running mastadon or other servers requires peering with every other related server. And it's on you to deliver messages, to push, to track state and progress. All the network work is on you to get your message out. So your server with your data has a ton of work to do. This doesn't scale well. See again Paul's scaling with open social.
If you do want to run your own atproto services, yes, you need to pull from the network to see what is relevant, you need a relay server, you need a pull. And you can! Running those relays is very cheap! The protocols scale really well & is super well optimized to be efficient to do! You can just do it!
The one particular thing you keep trying to demand is what makes AP so hard, so difficult, and scale so very badly. It's the worst part of activitypub, it makes it super hard and super expensive. Switching from AP push model to the relay doing pull model is the secret sauce that makes everything super lightweight and scalable, and that makes sync so much easier.
max-privatevoid 17 hours ago [-]
Yes, the relay design is very convenient for PDS operators on a technical level, but it comes at the enormous cost of having to trust a third party with message delivery, or, alternatively, running services that are much more expensive than an ActivityPub server.
jauntywundrkind 1 days ago [-]
You already could host either the web app, the knot (the repo), or the spindle (the runner) yourself, they were just harder to run yourself. I think it says a lot of good things that you can one by one pick which pieces of the system you want to host where!
It is a social network so I'm not sure what the issue about yes needing to read the network is. There are really good relays designed to help aggregate and filter the network. They can run on $5 VPS, processing the entire network, which is awesomely cheap, not just Tangled, which is awesome, what I would call a huge win. Paul has a talk on designing for scalability, about how it's possible to have such small boxes doing the network aggregation with so little resources, that appviews can then consume their interests from. solving for scale in open social networks, https://youtu.be/BoJnj2yPf14
The servers are definitely not keeping the whole network. The post talks to this some, but the new Knot2 retains a local copy of repo-relevant material (comments prs etc) in its own git tree, that collects what the network has done together, and makes it easy to ship/replicate, while also using that as a sync source to replicate back into atproto too, to make network visible.
Agreed that I really wish ForgeFed were showing much more clear progress. It seems like such a good idea, but it's been a number of years now and it's super murky what the progress is and where we are. Having >1 viable player in the decentralization of forges would be great. I haven't checked in a bit but I do read Forgejo release notes and my impression is it's been a very slow trickle.
rapnie 1 days ago [-]
> Having >1 viable player in the decentralization of forges would be great.
There are other projects other than Forgejo implementing ForgeFed. Forgejo itself has some federation support but AFAIK not based on ForgeFed. But they have a community contrib project that does.
When you say "they can run on a $5 VPS", do you mean that the entire server will be dedicated exclusively to processing ATProto data? I run an ActivityPub server on my $5 VPS that allows me to interact with everyone else on ActivityPub, and that VPS is hosting a lot more services than just that.
jauntywundrkind 1 days ago [-]
Yes I mean a $5 VPS that is processing all network traffic for the entire atmosphere.
Can you also fit a PDS to host yourself on on that VPS? Yeah I expect that it would fit very easily. PDS's have a lot less traffic hitting them than ActivityPub, they can be way smaller. They are quite lightly loaded! Because... there are relays in front of them!
paaloeye 1 days ago [-]
Is it actually smart to self-host when all those CVEs are dropping right and left? Sounds like a lot of maintenance for some marginal gains.
Zak 1 days ago [-]
I'm disappointed that issue tracking inside the VCS (probably as a separate repository, or at least a special branch) never got popular. That would reduce the importance of web-based code forges and make moving between them easy.
GCUMstlyHarmls 20 hours ago [-]
I believe radicle.dev (another federated forge) does this,
> Radicle’s Collaborative Objects (COBs) provide Radicle’s social primitive. This enables features such as issues, discussions and code review to be implemented as Git objects. Developers can extend Radicle’s capabilities to build any kind of collaboration flow they see fit.
At this point it's really the only forge I want to use going forward, considering that it sits nicely alongside all my other social data with ATProto.
lorbus 1 days ago [-]
Could this not use ActivityPub instead of ATProto?
ar-nelson 1 days ago [-]
Forgejo was supposed to, but that feature has been in limbo forever. For better or worse, ATProto is easier to implement, because most of the important details of ActivityPub are undocumented compatibility details of implementations like Mastodon (the spec alone isn't very useful for a working, compatible implementation).
AI would make it easier to implement and test complex protocols like this, but the community using Forgejo is mostly against it, which means it'll likely stay in limbo for a long time.
rebolek 2 days ago [-]
I would really love to use it but when are you going to support SHA256? I have SHA256 repo and I don’t want to rewrite all history especially when Git 3 is moving to SHA256 anyway.
icy 2 days ago [-]
We already do.
ignoramous 1 days ago [-]
Thanks. Now, my outie can enjoy all SHAs equally and not show preference for any over the others.
nerdypepper 2 days ago [-]
selfhosted knots default to sha256.
kalenkilgore 13 hours ago [-]
As someone who had their account flagged by github ruining months of work, this is interesting.
pfraze 1 days ago [-]
Congrats on the launch, tangled team!
monster_truck 1 days ago [-]
still don't understand what this is and the koolaid is so offputting
wealthville_net 1 days ago [-]
[flagged]
Rendered at 05:57:45 GMT+0000 (Coordinated Universal Time) with Vercel.
One musing: I did run into my first "issue" with federated Git hosting the other day while setting up Neovim on a new machine. One of the plugins I use is hosted on Tangled and I guess its backing Knot was down. This was awkward for two reasons:
1. It as unclear to me from the Tangled website the backing knot was the issue (for a while I thought it was something on my end)
2. I really had no backup plans for something like a Neovim plugin's source forge being down and, clearly, neither did the Neovim package manager as it just kept showing an error on every session I started with no way to fix it :).
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. 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.
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!
Someone (or some group) could also in theory go fully content-addressing with their data store, and make content available based on their hash, effectively layering that missing benefit on top of the existing architecture. Someone could probably vibecode this together in some hour(s) :)
I do agree that the sweet spot in federated git hosting could be a system merging the features of tangled with the features of radicle
But I have to admit that the design tradeoffs are really different
this problem could exist with any package manager, the go package manager is one example, where it allows specifying packages from any git url. we host a mirror of all git repositories on our infra, and serve that when the backing knot is down. you could choose to trust that and pull from there (verifying that the tarball has a known correct hash), the way the go package manager pulls from proxy.golang.org.
But yeah I recognize it's an issue for any package manager. I suppose I just forgot that even something like my local editor is reliant on remote forges now unless I go out of my way to mirror it all.
Happy to answer any questions at all.
So what’s the state of Tangled today? Say I have a Tangled server (instance? host?) up and running with my repos. Some stranger wants to contribute. What do they have to do before they can open issues or send PRs or whatever?
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/
This is great. I'm delighted at the idea of having my own knot hosting my projects, talking to my friend's knot, and coordinating on a global project's knot, all without having to lock everyone into one centralized point of failure (even mine). Amazing. I love it!
soon, repos will be able to declare a contribution policy: presently its open to all (anybody can open an issue), but owners can choose to limit this to just contributors for example.
Also, will Tangled support private repos that are only visible or fetchable to specific people? Would that even make sense in its model?
private repos are coming very soon, we have a working demo of private repositories.
i just found this too, more recent, possibly better! https://tangled.org/darko.mx/tangledart
From my very limited testing private repos were the big missing piece; interested in other areas yet to be filled in.
its undocumented at the moment but you push over https as well.
somebody has set up a git credential helper here: https://tangled.org/pds.dad/tangled-core/blob/feature%2Fgit-...
What can I expect as a developer using Tangled to build (and deploy) my app? What is the native platform? What are typical other CI systems that have been adapted to work on Tangled (Dagger, Drone, whatnot, especially if there are repos to demonstrate the adaption)? What can I expect as enterprise or lone developer using Tangled or self-hosting or federation?
The system is called Spindle, but what about it? What does it take inspiration from, what are things like it that would help us spool up on this?
Back when you first launched, I thought running a knot was already pretty easy :) Could you expand on how it's different now, and what part(s) aren't now easy to self-host, if there is any?
https://tangled.org/docs/self-hosting/indexer/
we have also stabilized lexicons, so if you are a selfhoster, you can expect to not require a breaking upgrade!
Try cloning on WSL, in the VM's filesystem, and let us all know how that goes.
I just wanted to read the source locally. I know things are getting worse by the month for developers on Windows because other developers are increasingly not giving a shit to support it, but it's odd to have a repo that doesn't even clone on windows.
Not building is common, not passing tests even if it builds is extremely common, but not even cloning is a new one.
I guess eventually I'll give up and switch to linux, but I'm still paid to work on Windows. I guess maybe it's finally time to look into a real dev-container setup for this kind of thing and I can do this all a bit more securely too.
For my visual impairments, macOS is currently fine, because I only really need magnification and I can get away without using much of it since everything I really deal with is free flowing text, like in a terminal or IDE. But as I need to rely more on screen readers, I anticipate I may have to consider switching. Switching to something other than Linux would break my heart, though.
Some feedback:-
* I found the UI on the homepage/timeline a bit busy - lots going on. Notifications, Recents, Announcements don't seem like they need to live on this page?
* The Activity chart on a users profile page seems a bit wild to me. I'd suggest simplifying it or just using what GitHub/GitLab use with their square grid activity chart - it's what users are most familiar with. It's kind of analagous to all the LLM/Chat applications in recent years - they all converged on the same UI because that's what works - no need to reinvent the wheel when users understand an existing pattern. Plus - it's better for marketing:- people like to share their activity on GitHub/GitLab as it quickly conveys how much work they've done over the year - your current page doesn't.
I am asking because I have been waiting for that change. I intend to make all the public repos from https://juju.bi (code forge I am building) interoperable with Tangled and basically behave as knot server.
Pre-update, code review UI was horrific compared to GitHub. Post-update, code review is much better, but "Comments" section without a "Comment" button is unforgivable. People are probably closing PRs right and left without knowing it. Shift-Enter is a submit action.
I'm a keyboard-first user, but for something which can end up in somebody's inbox notifications, UI button is the way to go.
I just don't understand how such a prolific pattern is being ignored.
I shared my vision for what it could have been in the first ATProto Private Data WG: https://www.youtube.com/watch?v=oYKA85oZc8U&t=3812s (basically Zanzibar, UCANN is also interesting) I have ideas for a new protocol that would be permissioned, more federated, but still draw on the good parts of atproto. It's geared towards small social (think discord server / facebook groups) than big social (most common apps we think of - with reposts, quotes, blocks - features I have sworn off).
The Bluesky team didn't join the conversation until pretty late and then picked their own proposal (blog post series, was not formal at that point).
Huh that's surprising to hear? What makes you think that? It feels like the whole point of this release is to make it easier to allow people to self host or federate whatever parts they want? That's what I got from their intro/opener!:
> But the centralised forge is crumbling. Relying on someone else for uptime, for features, and to be a good steward of your code hasn’t played out well. What has stood the test of time is email: Git to move the code, and email — an open protocol — to talk about it. At the cost of user experience, however.
> But the centralised forge is crumbling. Relying on someone else for uptime, for features, and to be a good steward of your code hasn’t played out well. What has stood the test of time is email: Git to move the code, and email — an open protocol — to talk about it. At the cost of user experience, however.
> Tangled aims to give you the best of both: the longevity of an open protocol, with the convenience and polish of a proper forge.
> It’s the first truly federated code forge — you can host code on your own servers and still collaborate seamlessly with others. Our approach is pragmatic: self-host just the parts you want, like Git hosting or CI runners, or all of it, including the API server and UI. Whatever you choose, you can still talk to everyone else.
The comment here from @icy emphasizes similar ability to let whomever host whatever parts of this they please:
> 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!) https://news.ycombinator.com/item?id=50306205
I don't see any mention of "their struggles around scaling centralized infrastructure". Is that just typical run of the mill low grade slander attack we see against atproto, more reflexive negativity? Or is there some actual interesting point here, that is perhaps even relevant to this tangled release?
Code hosting platforms are probably much more disjointed than microblogging platforms, so something like ActivityPub, where servers only keep track of content that users are actually interested in, would make much more sense. It's a shame that the people working on ForgeFed and/or Forgejo federation seemingly aren't making much progress.
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.
As has BlueSky, as long as you had enough hardware to keep up with the firehose. The protocol heavily lends itself to centralization due to this design. I think this should be obvious by the fact that you haven't considered self-hosting to be the default case.
> In our case, those are org.tangled.*.
I suppose my wording was inaccurate, but this is what I meant by "the entire network". My indexer would have to consume "all of Tangled" instead of the things related to the repos, orgs and people I am interested in. Correct?
> ActivityPub categorically does not make sense here because of how coupled identities are to instances.
I feel like this is more of an inconvenience rather than a dealbreaker. Having to point people to a new account ID on the off-chance you lose your domain seems like much less of a problem than having to deal with ATProto's firehose architecture.
We've already explained to you twice that this is incorrect, you don't need to do this. And that if you do want to do this for some ridiculous reason, just because, a $5 VPS can do it.
But you do acknowledge latter you are only talking about tangled records.
Currently very few people are worried about this problem, because all of the tangled traffic just isn't that big, and you can drop most of it very quickly with little impact. Relays do allow various kinds of filters though. You could use a service like Microcosm Constellation https://constellation.microcosm.blue/ that lets you find only records for your repos etc. That would work fine for finding the records pertinent to you!
No one does this right now, because the premise is faulty. There just really isn't any difficulty or cost of any note to having all the tangled records piped at you. Hopefully some day this gets worse, and that this becomes a good problem to have! One we already have tools (like constellation) to tackle.
In short: constellation is a (also easy to self host cheap light weight) service for reverse indexing, for finding records pertinent to you. Lots and lots of atproto apps use this for this kind of "find people making records about my stuff".
A ridiculous reason, such as being able to interact with the federated world from my own server directly, and not through a third-party service. Why is the simple concept of going to your own server to interact with the entire network, getting content directly from your friends' servers, and receiving interactions (e.g. PRs) directly from someone else's server such an afterthought in ATProto?
You can host your own data very cheaply. If you don't have to serve every single other server, and keep them all up to date, and can just pump some records out at aggregating relays, it makes it much easier for people to be online. You can run a massive PDS on a tiny ancient rpi.
Which is what activitypub doesn't do. It's protocols are very heavy and hard and stateful. Running mastadon or other servers requires peering with every other related server. And it's on you to deliver messages, to push, to track state and progress. All the network work is on you to get your message out. So your server with your data has a ton of work to do. This doesn't scale well. See again Paul's scaling with open social.
If you do want to run your own atproto services, yes, you need to pull from the network to see what is relevant, you need a relay server, you need a pull. And you can! Running those relays is very cheap! The protocols scale really well & is super well optimized to be efficient to do! You can just do it!
The one particular thing you keep trying to demand is what makes AP so hard, so difficult, and scale so very badly. It's the worst part of activitypub, it makes it super hard and super expensive. Switching from AP push model to the relay doing pull model is the secret sauce that makes everything super lightweight and scalable, and that makes sync so much easier.
It is a social network so I'm not sure what the issue about yes needing to read the network is. There are really good relays designed to help aggregate and filter the network. They can run on $5 VPS, processing the entire network, which is awesomely cheap, not just Tangled, which is awesome, what I would call a huge win. Paul has a talk on designing for scalability, about how it's possible to have such small boxes doing the network aggregation with so little resources, that appviews can then consume their interests from. solving for scale in open social networks, https://youtu.be/BoJnj2yPf14
The servers are definitely not keeping the whole network. The post talks to this some, but the new Knot2 retains a local copy of repo-relevant material (comments prs etc) in its own git tree, that collects what the network has done together, and makes it easy to ship/replicate, while also using that as a sync source to replicate back into atproto too, to make network visible.
Agreed that I really wish ForgeFed were showing much more clear progress. It seems like such a good idea, but it's been a number of years now and it's super murky what the progress is and where we are. Having >1 viable player in the decentralization of forges would be great. I haven't checked in a bit but I do read Forgejo release notes and my impression is it's been a very slow trickle.
There are other projects other than Forgejo implementing ForgeFed. Forgejo itself has some federation support but AFAIK not based on ForgeFed. But they have a community contrib project that does.
- https://codeberg.org/forgejo-contrib/federation
- https://codeberg.org/activitypub-rs/activityforge
- https://frogue.vit.am/~ololduck/Frogue
Gitlab has a community epic to add ActivityPub support, but that needs contributors:
- https://gitlab.com/groups/gitlab-org/-/work_items/11247
Generally you don't have to do this! There's lots of people running relays that are open access. But if you want your own it's very cheap. List of relays: https://tangled.org/firehose.club/community-firehose-list
Can you also fit a PDS to host yourself on on that VPS? Yeah I expect that it would fit very easily. PDS's have a lot less traffic hitting them than ActivityPub, they can be way smaller. They are quite lightly loaded! Because... there are relays in front of them!
> Radicle’s Collaborative Objects (COBs) provide Radicle’s social primitive. This enables features such as issues, discussions and code review to be implemented as Git objects. Developers can extend Radicle’s capabilities to build any kind of collaboration flow they see fit.
I do, however question the taste and judgment of any project that tells users to run `curl ...|sh`.
At this point it's really the only forge I want to use going forward, considering that it sits nicely alongside all my other social data with ATProto.
AI would make it easier to implement and test complex protocols like this, but the community using Forgejo is mostly against it, which means it'll likely stay in limbo for a long time.