Seedit is a selfhosted peer-to-peer Reddit Alternative using IPFS
doesn’t rely on any servers or instances .
We mainly use 3 technologies, which each have several protocols and specifications:
IPFS (for content-addressed, immutable content, similar to bittorrent) https://docs.ipfs.tech/ https://specs.ipfs.tech/
IPNS (for mutable content, public key addressed)
https://docs.ipfs.tech/concepts/ipns/
Libp2p Gossipsub (for publishing content and votes p2p)
https://docs.libp2p.io/concepts/pubsub/overview/
They also have a youtube channel where they cover how most of their tech works:
https://www.youtube.com/c/IPFSbot
the problem with federated social media is that each federated instance is just a regular centralized sites. They can censor each other, they can get taken down at any moment, and they are hard to run and manage. Whereas on p2p tech like bittorrent or bitcoin or plebbit, the p2p nodes don’t require domains, they just work straight out of the box. On plebbit, you open the app, and you’re instantly receiving p2p connections right away, just like a bittorrent client, no domain or server required. Users connect to your node directly, p2p, and nobody can stop you. P2P also scales infinitely, which is the reverse of centralized websites like federated instances: the more users there are, the faster it gets. And it’s impossible to censor at scale.
Seedit is not Nostr
nostr isnt p2p, the relays can censor you, the relays can run out of money and shut down, the relays can get DDOSed, they earn no money to serve your content.
the people running the relays are probably legally obligated to censor you by their jurisdiction. for example in the UK you go to jail for mean tweets. the person running the relay with mean content would probably go to jail if they set foot in the UK.
CP
-
the protocol is text only, to embed media, you need to host it on the regular ( Centralized ) internet, and then you link to it like https://example.com/image.jpg, and the host will stop hosting that image and report your IP.
-
the community creator can assign mods, mods can remove posts from that community. if a community is badly moderated, the user will never see it, it wont be recommended to him. the user can visit bad communities directly just like you can visit a bad website directly, but it’s not recommended to you so it’s safe to use.
it’s the same as bittorrent , this p2p tech can’r prevent people from sharing stuff, but on seedit you can’t share media, it’s text-only so the liability falls to the centralized provider of the embedded media from the link the user shares as text. Also being p2p, seedit is not private, so it can’t really be used for illegal activity
About ActivityPub
the problem with federated social media is that each federated instance is just a regular centralized sites. They can censor each other, they can get taken down at any moment, and they are hard to run and manage. Whereas on p2p tech like bittorrent, p2p nodes don’t require domains, they just work straight out of the box. On seedit, you open the app, and you’re instantly receiving p2p connections right away, just like a bittorrent client, no domain or server required. Users connect to your node directly, p2p, and nobody can stop you. P2P also scales infinitely, which is the reverse of centralized websites like federated instances: the more users there are, the faster it gets. And it’s impossible to censor at scale.
Also the code is fully open source
I’m concerned about the large amount of low quality, vaporware/crypto applications built on IPFS which is the same core technology used here. It’s concerning how many clicks it takes to get technical specs for the underlying work, like libp2p for the network layer, which itself espouses only vague ideas on its main website that seems to focus a lot more on presentation than technical merit. Even the GitHub admits that the spec that most of these apps are relying upon is, well, unspecified.
Your project source downloads and runs an executable. That’s a little bit SUS; it would be much better if you compiled/built this core code as part of your build process, else, it’s not much in the way of source code, no? But, it works. It seems to delegate just fine, and few understand how to actually talk IPFS directly. But, this is the most important part!
I think the biggest tell that IPFS borders on vaporware is that there’s very little discussion about concrete specifications and the main problem faced by all DHTs: how you get your data to actually stay hosted on the network over time. These ideas are not new, and you may be better served building your app on technology that has spent vastly more time understanding the fundamental problems.
This is how you write a spec without actually writing a spec. And I’ve written a lot of specs.
This is how you write a spec. Excruciating detail of what actually gets sent over the wire at different levels of the design starting from the very bottom.
Anyway, just my 2c. It’s cool you’ve got functionality at this level and that’s commendable, but I feel it’s built on shoddy foundation of an immature technology. At least it should be easy to migrate to something else in the future as the distributed technology is offload to a separate binary anyway.
Note: Various edits for clarification and to ensure I focus on the code and not the human.