We would still be limited by the patch order mattering in a snapshot-based VCS which hurts the ability to reasonably work conflict-free in a decentralized manner.
Let’s say you’ve got a function f() in a file that is called in multiple places. Patch A adds a new place where f() is called. Patch B renames f() to g() and updates all call sites.
We cannot commute these patches, can we? If patch B comes first, then when patch A lands, it will be using the old name in a codebase that has been updated to use the new name. The resulting code is therefore only valid if A comes before B.
Not all patches commute, such as when they depend on one another, but many patches do commute—tautologically, in the way that 1 + 2 = 2 + 1 so order doesn’t matter in these cases. You deal with these conflict issues if/when they come up rather than every pull if your patch order is out of sync (rerere is not foolproof, merge commits are incredible noisy & even they cause merge conflict issues sometimes). This does mean Alice can pull in patches from Bob then Carol, while Carol can pull from Alice then Bob & if it commutes, no conflict.
it looks like you will need a PDS (to host issues / repo pointers), a Tangled AppView, a Knot server (to host the git repos), and a Jetstream instance for the AppView’s ingester (you will need to point Jetstream at your PDS’ subscribeRepos XRPC endpoint instead of the bsky.network central firehose)
it also seems like its current state is hardcoded to connect to jetstream1.us-west.bsky.network, since no explicit client config is passed in from appview/state/state.go or from cmd/knotserver/main.go, so you’ll need to amend that
Interesting, thank you! Given that you’d be directly using your PDS’s subscribeRepos endpoint, would this support collaboration between multiple PDSes?
to do so, you’ll need to multiplex and resequence multiple PDS’ subscription endpoints together (≡ be a non-archival relay)
cerulea/relay can do this, but you’ll need to submit com.atproto.sync.requestCrawls to it for each PDS manually (or add your cerulea instance to each PDS’ PDS_CRAWLERS environment variable). then you can point jetstream at the cerulea instance
Understood! Thanks for all the links, lots of reading up to do. The AP ecosystem still feels very bsky.network focused; i’m excited for decentralization to become more of a first class concern, but I’m glad it’s possible.
This is cool! How are you implementing issues and such? IIRC, Radicle is using some lesser-known GitHub features to store them in the repo in a transparent way. Or are you using ATProto itself for such things?
There are several models for decentralized code collaboration platforms, ranging from ActivityPub’s (Forgejo) federated model, to Radicle’s entirely P2P model.
I didn’t understand this. As far as I’m aware, Forgejo has no relationship with ActivityPub.
I thought maybe they meant that ActivityPub’s development happens on a Forgejo server, but the ActivityPub spec points to Github as the official repo.
This is one of the coolest new things I’ve seen on the internet lately - I can’t put my finger on why, but it has a very solarpunk feel to it.
Between this, forgefed, and radicle, it does feel like we’re starting to move in the right direction, finally!
We would still be limited by the patch order mattering in a snapshot-based VCS which hurts the ability to reasonably work conflict-free in a decentralized manner.
Can you avoid patch ordering in general?
Let’s say you’ve got a function
f()in a file that is called in multiple places. Patch A adds a new place wheref()is called. Patch B renamesf()tog()and updates all call sites.We cannot commute these patches, can we? If patch B comes first, then when patch A lands, it will be using the old name in a codebase that has been updated to use the new name. The resulting code is therefore only valid if A comes before B.
Not all patches commute, such as when they depend on one another, but many patches do commute—tautologically, in the way that 1 + 2 = 2 + 1 so order doesn’t matter in these cases. You deal with these conflict issues if/when they come up rather than every pull if your patch order is out of sync (
rerereis not foolproof, merge commits are incredible noisy & even they cause merge conflict issues sometimes). This does mean Alice can pull in patches from Bob then Carol, while Carol can pull from Alice then Bob & if it commutes, no conflict.Is this currently self-hostable in its entirety? That is, if I run a PDS and Tangled appview, is any other infrastructure needed?
it looks like you will need a PDS (to host issues / repo pointers), a Tangled AppView, a Knot server (to host the git repos), and a Jetstream instance for the AppView’s ingester (you will need to point Jetstream at your PDS’ subscribeRepos XRPC endpoint instead of the bsky.network central firehose)
it also seems like its current state is hardcoded to connect to
jetstream1.us-west.bsky.network, since no explicit client config is passed in from appview/state/state.go or from cmd/knotserver/main.go, so you’ll need to amend thatInteresting, thank you! Given that you’d be directly using your PDS’s subscribeRepos endpoint, would this support collaboration between multiple PDSes?
to do so, you’ll need to multiplex and resequence multiple PDS’ subscription endpoints together (≡ be a non-archival relay)
cerulea/relay can do this, but you’ll need to submit
com.atproto.sync.requestCrawls to it for each PDS manually (or add your cerulea instance to each PDS’PDS_CRAWLERSenvironment variable). then you can point jetstream at the cerulea instanceUnderstood! Thanks for all the links, lots of reading up to do. The AP ecosystem still feels very bsky.network focused; i’m excited for decentralization to become more of a first class concern, but I’m glad it’s possible.
This is cool! How are you implementing issues and such? IIRC, Radicle is using some lesser-known GitHub features to store them in the repo in a transparent way. Or are you using ATProto itself for such things?
Thanks! We’re indeed using atproto for this. For example: https://pdsls.dev/at://did:plc:44ybard66vv44zksje25o7dz/sh.tangled.repo.issue/3ljgdwiejtk22
Is there a link where I can read about Radicle’s use of git (Github?) plumbing? Sounds interesting.
edit: found it - https://radicle.xyz/guides/protocol#collaborative-objects
yup! issues are stored on PDSs, here is a sample issue record, for example.
we want all social bits to be stored “on protocol”.
Radicle uses lesser-known Git features, not GitHub features
Oops! I blame autocorrect. Yeah.
I didn’t understand this. As far as I’m aware, Forgejo has no relationship with ActivityPub.
I thought maybe they meant that ActivityPub’s development happens on a Forgejo server, but the ActivityPub spec points to Github as the official repo.
i think they are referencing forgefed (https://forgefed.org/) but the last time i looked forgejo was still working on their implementation of it.
That was my bad! I will amend that to say Forgefed.
https://forgefed.org/
Can I get an invite without having to go though the pain of setting up IRC?
I had the same reaction, but web.libera.chat ended up being fine to use when I dropped by.
i’d suggest using kiwiirc anonymously if you just want to drop in and request access!