There is a big exception here. You sign commits, so each update comes with some proof of the identity of the author. I like how simple this is, and generally prefer it over the way Mastodon and other federated services handle identity.
A non-federated decentralized social protocol based on Git
11–20 of 41 posts
Re: A non-federated decentralized social protocol based on Git
#12How do notifications work with this?
Re: A non-federated decentralized social protocol based on Git
#13Re: A non-federated decentralized social protocol based on Git
#14I'm sorry but I believe I'm missing something here. How does this solve any of the problems that people commonly have with decentralized, federated social networks? * You're still either hosting your own, or at the whim of whomever hosts your repository. Mastodon.social or GitHub. * Hosting your own Git is not particularly easier than hosting your own GoTo Social or Akkoma. * What if you end up with either a big foll…
And I don't reaaally see how this tool solves that problem. Or any of the other problems you mentioned.
But that said, Mastodon/ActivityPub don't really feel like mature solutions yet. It's incredibly opaque how instances interact, and self-hosting is an exercise in frustration as you try to figure out why A sees your reactions but B does not and you can get notifications for C's reactions but not A's, but B's replies and not… I gave up after a while. It's more opaque than even email self-hosting, at least exim and postfix have fairly verbose error logging.
Re: A non-federated decentralized social protocol based on Git
#15Unless I misunderstand, this is federated - each instance stores data related to its user, and fetches from other instances the data it's interested in (from other users the user is following.) It also doesn't do much to address the reasons users in federated systems tend to congregate around large(r) servers, like discoverability and reliability. It's a neat PoC but I think the communication needs some work.
If its based on git then more than likely, copies can be made and shared separate from the user instance. Users own their signature so changes cannot be forged but valid data can be proxied and cached. User data is fully portable from one vendor to the next. Would you call git federated or decentralized?
Re: A non-federated decentralized social protocol based on Git
#16Re: A non-federated decentralized social protocol based on Git
#17I'm sorry but I believe I'm missing something here. How does this solve any of the problems that people commonly have with decentralized, federated social networks? * You're still either hosting your own, or at the whim of whomever hosts your repository. Mastodon.social or GitHub. * Hosting your own Git is not particularly easier than hosting your own GoTo Social or Akkoma. * What if you end up with either a big foll…
Git makes it easy to make copies, but its nature of having one designated "origin" remote per repository that serves as upstream source of truth (on platforms like github also across forks) makes it not really federated/decentralized the way Mastodon et al. are. And I don't reaaally see how this tool solves that problem. Or any of the other problems you mentioned. But that said, Mastodon/ActivityPub don't really feel…
That makes sense. Each Activitypub server might also be considered the source of truth for any given post, but since you're usually going to fetch them from your own instance that your account lives on you're not getting it directly from there unless you specifically do it yourself.
> But that said, Mastodon/ActivityPub don't really feel like mature solutions yet.
Yeah, that makes sense. I think this is partly because Activitypub is both quite opinionated, but also gives you quite some wiggle room with how you implement different functionality, like defederation. And of course the most well known software in that space is effectively what all others have to follow.
Git is probably a more stable protocol, but then again ActivityPub is served over HTTP, which is also pretty stable. I believe the same issues would befall this as well, since Git, to me, doesn't seem to be the biggest factor in this, and more the append-only nature of it. I've never been a big fan of append-only social networks.
I've been running a Mastodon server for a couple of years now and have had relatively few federation issues, luckily. But I do agree that trudging through the logs and figuring out what's going on is not exactly ideal, not to mention debugging other issues like if something went wrong during the key exchange with your server and a remote one, or if you accidentally lose your key and suddenly can't talk to any other instance since they won't trust your old domain with the new key. But you might run into similar issues with this, right?
Edit: If it came across as downplaying the project or it's author then that wasn't my intention at all. These were just some thoughts that immediately popped into my head when I saw this. They may well have thought through answers to my not thought through questions, and I certainly don't mean to pretend like I know better.
Re: A non-federated decentralized social protocol based on Git
#18As a long-time user (and writer) of static site generators, I welcome these ideas, as I think these would allow us to organize static sites into some kind of decentralized social networks. Think of this as a bulkier version of RSS, because - for most practical cases - it is relative cheap to just fetch everything from a source and present it in a consistent way.
Even if people were using centralized git repositories, a separate naming service could allow easy (and cheap/free) redirects, so data migration wouldn't be an issue.
Can this be done with mastadon? Of course. But it requires a database server and other moving parts that need occasional maintenance. Treating the social network as a network of static sites makes operations (and federation) so much easier.
Would this be this specific project that wins us over? Maybe not, we shall see. But I think the concept could evolve into something useful.
Re: A non-federated decentralized social protocol based on Git
#19Earlier quoted context omitted.
When the federation is per-user, that's typically called "peer-to-peer" rather than federated...?
Also, git doesn't work p2p, it uses centralized servers. If i understand correctly, the only real difference between Twitter and this is that you have your data downloaded, so switching to a new platform is a matter of adding a new remote and pushing it there.
Re: A non-federated decentralized social protocol based on Git
#20I wanted to know the design decisions behind how Kademlia worked in detail.
Glad to see this… wondering why we need it if we have Dat/Hypercore and beaker browser, which already uses Secure Kademlia DHT for swarming and follows up with SLEEP protocol instead of Git. It is encrypted and secure, to boot.
But those saying this is federated are wrong. It is peer to peer, just like Git is. Email is federated (the domain part is even a centrally controlled database). Having said that, git can be hosted even on your own computer!