[HN Gopher] A non-federated decentralized social protocol based ...
___________________________________________________________________
A non-federated decentralized social protocol based on Git
Author : petar
Score : 63 points
Date : 2023-03-28 15:17 UTC (7 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| petar wrote:
| The 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...
| NoraCodes wrote:
| Unless 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.
| jayd16 wrote:
| 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?
| NoraCodes wrote:
| So far as I understand, Git is both federated and
| decentralized - but I could easily be misunderstanding the
| definition of "federated" in this context.
| mhluongo wrote:
| When the federation is per-user, that's typically called "peer-
| to-peer" rather than federated...?
| teawrecks wrote:
| 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.
| jayd16 wrote:
| You can certainly work with git in a p2p fashion.
| gtop3 wrote:
| My understanding of this implementation is you can use
| arbitrary git urls to follow. That could point to any
| process serving data. P2P is 100% possible.
|
| It would be smart to use a personal domain for the git url
| you give your followers, so you can update the hosting
| location without causing any disruption.
| adastra22 wrote:
| Git was designed from the beginning to be used p2p. It's
| how the Linux kernel development is done.
| astrobe_ wrote:
| I'm pretty sure _git-daemon_ does work p2p, but maybe that
| 's a different p2p you have in mind.
| isoos wrote:
| > Every user stores their application state in a git repo they
| own and control. No other infrastructure is necessary!
|
| 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.
|
| 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.
| ClawsOnPaws wrote:
| 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?
|
| * 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 following, or a big
| follower list? Aren't you going to be rate limited by GitHub?
|
| * Is signing up for GitHub easier than signing up for
| mastodon.social, especially if Mastodon et al already have good
| mobile clients?
|
| * What about moderation?
|
| * What about media?
|
| And I mean... Isn't Git federated by nature? Multiple machines
| store multiple copies of the data. That's defederation isn't it?
|
| But OK, let's put the federated social networks we do have aside
| for a moment.
|
| The site says: Every user stores their application state in a git
| repo they own and control.
|
| 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?
|
| 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?
| jayd16 wrote:
| >But you don't do that if you're on GitHub, right?
|
| How do you push to github without a repo you own and control?
| Are people pushing patches through the web interface or
| something?
| creshal wrote:
| 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 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.
| ClawsOnPaws wrote:
| > 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.
|
| 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.
| piedar wrote:
| > 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.
| creshal wrote:
| 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.
| numtel wrote:
| If you want decentralized without hosting your own servers, you
| can store data on a public blockchain. Each interaction pays a
| small amount of gas that grants them hosting indefinitely.
| Protocols are a progression from platforms since they can be
| ownerless. Blockchains enable protocols by acting as a general
| purpose database.
|
| This is what I'm doing with https://nonphysical.systems
|
| It's still under construction so it's on Polygon mumbai testnet
| therefore gas is free. The source is linked in the first
| message board.
| blooalien wrote:
| > "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]
| tedunangst wrote:
| It's a more difficult to use version of rss.
| cryptonector wrote:
| Are we reinventing Usenet?
| Dalewyn wrote:
| 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.
| msla wrote:
| That's what it seems like: Usenet built on Git instead of NNTP,
| which was, itself, a reinvention of Usenet built on UUCP.
| ape4 wrote:
| I still miss it
| EGreg wrote:
| I know Petar Maymoukov and met w him when we started designing
| Intercloud.
|
| I 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!
| gtop3 wrote:
| 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.
|
| 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.
| csense wrote:
| The author is well-known for creating Kademlia [1], a distributed
| hash table used to resolve BitTorrent magnet links.
|
| [1] https://en.wikipedia.org/wiki/Kademlia
| jmount wrote:
| Seems like it all gets wiped by one git force-push.
| jdthedisciple wrote:
| How do notifications work with this?
| uptown wrote:
| I'll let you know.
| jdthedisciple wrote:
| But will I get notified?
| uptown wrote:
| See! It's already working!
___________________________________________________________________
(page generated 2023-03-28 23:00 UTC)