Are we reinventing Usenet?
Any time I hear the word "federated" in tech contexts I am led to presume someone is attempting to reinvent the wheel, and badly at that.
A non-federated decentralized social protocol based on Git
31–40 of 41 posts
Re: A non-federated decentralized social protocol based on Git
#32I'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…
> "Hosting your own Git is not particularly easier than hosting your own GoTo Social or Akkoma." Easiest way I've found (so far) to "host your own git" is https://github.com/charmbracelet/soft-serve
[deleted]
Re: A non-federated decentralized social protocol based on Git
#33The underlying software architecture and the motivation behind it are outlined in the whitepaper of the (more complex) gov4git project: https://github.com/gov4git/doc/blob/main/whitepaper/whitepap...
Re: A non-federated decentralized social protocol based on Git
#34Earlier quoted context omitted.
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…
> one designated "origin" remote Git is not limited to a single remote. The default remote is called "origin" but there's nothing particularly special about it.
But git gives you nothing to handle more complicated topologies, all remotes you interact with have to result in a linear history with everything on all other remotes… unless you feel like doing a manual merge every time you update your social media feed. Making that work automagically needs another layer on top of git, none of which seems documented here.
Re: A non-federated decentralized social protocol based on Git
#35I'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…
Kinda does look like round peg square hole situation.
"Federated network" could be modeled by a stream of posts (comments, tweets, whatever else) that are either a start ("root") of conversation or reply to one or more previous post(s), so it does form a graph. Then a bunch of "indexes" like "each post with this tag", usually ordered via some kind of filter (time, how popular the twat posting it is, removing any offensive or NSFW ones etc).
But there is really nothing to merge and not much else common to git aside from sitting on its store and protocol
Re: A non-federated decentralized social protocol based on Git
#36How do notifications work with this?
maybe by emailing pull request to all your contacts ;-)
Re: A non-federated decentralized social protocol based on Git
#37There are a few ideas that I really like here:
- Managing data (push/pull/etc) in a common, widely-supported protocol (git)
- which has a large, stable, and free-as-in-beer implementation (GitHub)
- as well as some major competitors (Bitbucket/GitLab)
- and is possible to self-host (gitea, OSS GitLab)
What I'd love to see:
- 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
- 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
Re: A non-federated decentralized social protocol based on Git
#38I'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…
It's a more difficult to use version of rss.
RSS really feels where the whole distributed thing peaked. I can subscribe to who I want where I want and if I want to see some new stuff either follow "what people I follow link to in their blogs" or get RSS channel of some topical federator.
All it missed was similiar distributed way to conversate instead of just reading and maybe leaving a comment on a blog
Re: A non-federated decentralized social protocol based on Git
#39I 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 https://github.com/social4git/social4git/blob/main/doc/walkt... how this even works.
Maybe some illustration would help to explain data and/or control flow?
The number of pilot users would still deserve growing: https://github.com/social4git/social4git/blob/main/doc/direc...
Re: A non-federated decentralized social protocol based on Git
#40What'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.
Nostr is another one that is more lightweight without the Merkel tree but is seeing some traction.