I'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?<p>* You're still either hosting your own, or at the whim of whomever hosts your repository. Mastodon.social or GitHub.<p>* Hosting your own Git is not particularly easier than hosting your own GoTo Social or Akkoma.<p>* What if you end up with either a big following, or a big follower list? Aren't you going to be rate limited by GitHub?<p>* Is signing up for GitHub easier than signing up for mastodon.social, especially if Mastodon et al already have good mobile clients?<p>* What about moderation?<p>* What about media?<p>And I mean... Isn't Git federated by nature? Multiple machines store multiple copies of the data. That's defederation isn't it?<p>But OK, let's put the federated social networks we do have aside for a moment.<p>The site says: Every user stores their application state in a git repo they own and control.<p>But you don't do that if you're on GitHub, right? Not really, anyway. What is the benefit from doing this over git? What if I want to delete something? What is the overhead of the git protocol?<p>If it's just a toy, then that's totally cool with me. But it says that Microsoft Research is involved. I'm a bit confused. What is this?
The author is well-known for creating Kademlia [1], a distributed hash table used to resolve BitTorrent magnet links.<p>[1] <a href="https://en.wikipedia.org/wiki/Kademlia" rel="nofollow">https://en.wikipedia.org/wiki/Kademlia</a>
> Every user stores their application state in a git repo they own and control. No other infrastructure is necessary!<p>As 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.<p>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.<p>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.<p>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.
I know Petar Maymoukov and met w him when we started designing Intercloud.<p>I wanted to know the design decisions behind how Kademlia worked in detail.<p>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.<p>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!
Unless I misunderstand, this <i>is</i> 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.)<p>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.<p>It's a neat PoC but I think the communication needs some work.
The underlying software architecture and the motivation behind it are outlined in the whitepaper of the (more complex) gov4git project: <a href="https://github.com/gov4git/doc/blob/main/whitepaper/whitepaper.md">https://github.com/gov4git/doc/blob/main/whitepaper/whitepap...</a>
I am always highly skeptical of these applications that use git to store non-code data. Often many of the key features of git aren't applicable to other problem spaces and this makes everything less efficient.<p>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.
I certainly support the idea that alternatives to what we currently have are
needed. But I must admit even as a software developer I feel confused when looking at <a href="https://github.com/social4git/social4git/blob/main/doc/walkthrough.sh">https://github.com/social4git/social4git/blob/main/doc/walkt...</a> how this even works.<p>Maybe some illustration would help to explain data and/or control flow?<p>The number of pilot users would still deserve growing: <a href="https://github.com/social4git/social4git/blob/main/doc/directory.md">https://github.com/social4git/social4git/blob/main/doc/direc...</a>
There are a few ideas that I really like here:<p>- Managing data (push/pull/etc) in a common, widely-supported protocol (git)<p>- which has a large, stable, and free-as-in-beer implementation (GitHub)<p>- as well as some major competitors (Bitbucket/GitLab)<p>- and is possible to self-host (gitea, OSS GitLab)<p>What I'd love to see:<p>- posts are currently in JSON format. Make it something more readable (like Markdown+YAML), at least optionally. That way people can interact _directly_ in GitHub, instead of using a janky client<p>- The main problem with decentralized frameworks is always "search and discoverability". Someone needs to aggregate all the data in a centralized database and make it easy for others to pick through
What's the advantage of this over a design like Scuttlebutt / Farcaster? They have the same properties (signed messages, Merkel trees to ensure data isn't changed) but are engineered for social media.<p>Nostr is another one that is more lightweight without the Merkel tree but is seeing some traction.