Rinse - Bitsocial

Working on Bitsocial, an open-source peer-to-peer protocol for social apps, with no servers, where users and communities are cryptographic property

Public Key

npub1rufapk4ust6fgraf3n2nvlq5c67m0vk5yy270s8myflh0e786e4sqzvhny

Profile Code

nprofile1qqsp7y7sm27g9ay5p75ce4fk0s2vd0dhkt2zz908crajylmhulrav6cpzpmhxue69uhkummnw3ezuamfdejsz9rhwden5te0wfjkccte9ejxzmt4wvhxjmcshlv7y

Publishing to

nostr.wine

relay.damus.io

nos.lol

Author Public Key

npub1rufapk4ust6fgraf3n2nvlq5c67m0vk5yy270s8myflh0e786e4sqzvhny

Show more details

Last Notes

2026-05-14 14:44:44 CEST

- reply

You can try it out by downloading the desktop apps or running a bitsocial-cli docker container and then use the hosted webuis, https://github.com/bitsocialnet/bitsocial-cli
Its pretty fast especially on desktop thanks to udp+quic support.
I think your issues with IPFS stemmed from using their DHT, yes its pretty terrible and slow. Unfortunately we struggled for a long time with it till we realized the better way would be to have http routers (similar to bittorrent trackers) as the default mechanism to find providers of content, and we could have DHT as a fallback in case http routers are offline or start censoring. You could also get creative and have .bso names attach http routers used by community in a text record, though with how light http routers its very easy to replace and spin up new ones all the time.
https://bitsocial.net/docs/peer-to-peer-protocol/

2026-05-14 13:23:37 CEST

- reply

@npub180c…h6w6 I said a server but that's basically any machine you have laying around, since with running p2p the cost of scaling network doesn't scale with the number of nodes, the cost of running a node is pretty low. I'm sure if somebody spends a weekend on it we would get a fully running Bitsocial node on Android that hosts a community. You could probably host thousands of communities on a raspberry pi easily.
Running communities is free in the economical sense, in the same way seeding a bittorrent file is "free" because there's no DNS to be bought, and u basically have to only leave the app running in the background

2026-05-14 12:09:31 CEST

- reply

it depends on how you wanna set it up, but whats important is `bitsocial` txt record getting updated on the domain. In ENS you can also set different roles for different wallet addresses, one can be the ultimate owner and rest could be just "managers" that can be revoked anytime. There's lots of ways to play with it

2026-05-14 09:05:29 CEST

- reply

if the community has a name domain like .bso (which is a ENS domain for now), then the name can be managed by a multisig which can vote to update the keypair. You can also have DAOs managing your .bso since its technically just an NFT

2026-05-14 07:28:36 CEST

- reply

Yes I do wish IPFS spent more time with "selective seeding", seems like most of the API calls keep and provide blocks for ~24h (last time I checked) which is not ideal for social media where can people can stumble upon a kind of content you dont your ip address associated with...

2026-05-14 07:24:24 CEST

- reply

Yes it is surprisingly quick with websocket in the browser. Initially we had to rely on IPFS gateways in browser but I think very soon we could have reliable p2p social media in browser

2026-05-14 07:21:47 CEST

- reply

I dont think this chokepoint is a bad thing. In our current design a community is similar to a bitcoin wallet. You own it, nobody can do anything with it unless u specifically authorize, or delegate somebody to. There's no way of changing that without adding lots of complexities

2026-05-14 07:19:03 CEST

- reply

Its always possible to have http trackers like BitTorrent, and a DHT fallback. It worked pretty well for BitTorrent and thats what we're using at the moment

2026-05-14 07:16:46 CEST

- reply

The assumption within our protocol is that the community owner will stay online or delegate somebody to stay online for them. They need to be online to receive publications and respond with challenges if needed to them. That's the price of having an arbitaerry anti-spam functionality for each community.
Eventually we would have lots of public RPCs where people can delegate their community hosting while maintaining ownership by owning the .bso name of that community

2026-05-14 07:11:33 CEST

- reply

nostr relays are not like communities in Bitsocial at all.
A "community" in Bitsocial is an IPNS record that is published by the community owner (with their own or delegated node). The community node has no power or influence over the network at all. Peers who want to publish will gossip it through pubsub topic of that community and it will eventually reach the community node. Then community will decide whether its a spam, or not, and decide whether to send a challenge.
Running a community is also free since u would only need an IPFS node and then u would generate a keypair.
In Nostr, From my understanding you have to share a relay with somebody in order to reach them. Which means there's always a third party in any kind of social interactions in nostr. There's no such thing in Bitsocial, if u could access a community node by any means you could publish to that community directly.
Running a relay is not free either, you have to buy the domain + maintain + stay up to date on spam etc. No matter how easy it is to add relays eventually most clients/people would settle on 5-10 relays to announce to. Those relays can then be pressured through DNS seizures to block people or force kyc.
In Bitsocial when we designed it from the bottom up our core assumption was that DNS can compromised at any moment. All of our data primitives are either IPFS immutable files (comments) or mutable community records (IPNS, no need for DNS).

2026-05-11 12:22:37 CEST

- reply

Correct, I suppose somebody can publish a bitsocial-cli fork with mesh network support for these kind of cases specifically, but I dont know how would that look like in practice

2026-05-11 10:39:33 CEST

- reply

Community owners will pick an RPC with high up time, unless ur describing a sceneario where peer B tries to connect but is banned (china or Russian ISPs). In that case the bigger the network grows the more likely a peer will find a provider of content who is not banned.

2026-05-11 10:26:33 CEST

- reply

not federated*

2026-05-11 10:13:22 CEST

- reply

just to clarify, the process of communicating with a community is unrelated to the client, and is part of the core protocol pkc-js implementation https://github.com/pkcprotocol/pkc-js
If in the case the community owner is offline and can no longer publish updates, then yes the community records will go into read-only mode until the node is back up OR eventually all peers stop seeding it and it dies in the same way old bittorrent links die because no one seeds.
Additionally mobile users can't run communities since its extremely battery intensive and IPFS stack is not well tested in Android and I can't imagine it performing well.
To fix that problem we will have non-custodial RPC service for Bitsocial apps. Bitsocial RPC will let users manage community nodes remotely, while preserving the option to self-host or run competing RPC infrastructure. This is phase 2 of our project, more info about it here https://bitsocial.net/docs/permissionless-public-rpc/

2026-05-11 09:40:14 CEST

- reply

Check out Bitsocial, its federated nor uses relays. Its content-addressable and much closer to BitTorrent in its design. All users seed by default, nodes run on cheap hardware, and each community represented by a keypair so no need to trust a relay/server

2026-05-11 09:34:04 CEST

- reply

Netsplits are not really relevant for a p2p system where everybody is a server cause they're a node.
Also the mutability layer of Bitsocial (IPNS) is essentially a pubsub topic thats owned by keypair who's publishing to the pubsub topic on every update. Every update has to be signed by that keypair.
Its possible if the key is leaked or stolen it could get messy with multiple nodes publishing to the same pubsub topic, but that's where the .bso names come in (paid, but optional). https://github.com/bitsocialnet/bso-resolver

2026-05-11 09:24:35 CEST

- reply

We did consider Pubkey with Bitsocial at some point but since we already had IPFS as our core backend, and IPNS already solved the problem of mutable names, we opted to go with it. But truth is both PKAAR (Pubskey mutable names) and IPNS work fine.
Our protocol is more specfically geared towards apps, but its possible for a community to add custom props to its json record, and those props can be used for custom functionality or custom clients.

2026-05-11 09:11:22 CEST

- reply

Seems like somebody already done the work, https://github.com/AkitaEngineering/Akita-Meshtastic-IPFS-Plugin
In general anything that works over IPFS is applicable for our protocol since its our core backend and medium of transport

2026-05-11 08:53:31 CEST

- reply

u can always install desktop/android apps which embed their html/css/js + its own IPFS p2p node.
Additionally its possible to have a light p2p node in web where a browser peer can fetch and publish content but not seed. For example on https://p2p.5chan.app it does not use any centralized RPCs to fetch or publish any content. It connects to peers directly using websocket.
Also web apps dont embed any content in them, they only embed the p2p backend client code, so the operator of 5chan.app has no way of seeing what kind of communities you're intereacting with. There's no liability there, his only job is giving u the static html/css/js

2026-05-11 08:47:26 CEST

- reply

A community is a bitsocial concept, a community is essentially a keypair with comment records and metadata. Users connect to communities to publish content to them. A community has 0 power over a user interacting with other communities or peers, unlike a nostr relay.
More on it here, https://bitsocial.net/docs/peer-to-peer-protocol/

2026-05-11 04:01:02 CEST

- reply

if the relay decides what's spam, the relay is the choke point, also from my understanding the relay you use decide how many people you can reach. in bitsocial each community runs its own challenge (captcha, rate limit, token gate, payment, IP filters, custom code) and the operator's node validates challenge responses directly over pubsub.
we're not actually inspired by scuttlebutt, we're built on ipfs/libp2p where everything is content-addressable. community pubkey is the address gossipsub for realtime challenge exchange. We're much closer to bittorrent imo.

2026-05-11 03:51:03 CEST

- reply

>How will moderation deletes work?
a community in Bitsocial is essentially an IPNS which is a keypair owned by the community owner. The owner can push any kind of updates to it, which includes removing specific posts/comments from it after any kind of moderation.
Although in theory if a comment is already published and has a CID and it gets purged by the community owner and its node, its possible somebody else from the network will perpetually provide that comment to anybody who asked. But that purged comment won't appear on the community record, its essentially an "orphan", with no way of discovering it unless u specifically know the CID or been given the CID by somebody else.
Additionally currently web UIs display an alert if a comment is "orphan" so people don't get scammed by them.
>Votes
Authors can publish a vote and the community will receive it and add a counter (wheter its +1 or -1) to the comment getting voted on. A comment has two parts, CommentIpfs (permanent, with most of its fields signed and written by its author) and CommentUpdate (ephemeral, generated by the community owner). Two fields `upvoteCount` and `downvoteCount` will be added to the Comment, so anybody listening to updates from the comment will receive a new update with `upvoteCount +1`.
>React
Currently the easiest way to set up a web UI is with the react hooks we've built, eventually we're gonna have other libraries.
The react hooks use our general typescript sdk, pkc-js, https://github.com/pkcprotocol/pkc-js
If u wanna play around with the protocol automation I would recommend you set up your own bitsocial-cli node https://github.com/bitsocialnet/bitsocial-cli
Then after that you connect to that node with `await PKC({pkcRpcClientsOptions: ["ws://localhost:9138"]})`
Currently we dont have a lot of good docs since we're more focused on capture an MVP for image boards. You can let me know if u have any questions!
Btw check out p2p.5chan.app, its a light p2p node in the browser (only leech, no seeding) and it connects to peers directly to fetch content and publish as well. No centralized RPC!

2026-05-10 02:32:17 CEST

- reply

the issue with nostr is not just that it's not P2P, it's also that you can't moderate the replies to your own comments or the posts in your communities via some automated P2P challenge system, it seems like the spam moderation is just non existent/not effective (like having to pay relays to post) or fully centralized.
without P2P downloading, nostr design doesn't really make sense, relays just get hammered with tons of bandwidth for free which isnt sustainable, unlike p2p which scales infinitely with more peers.
also without being able to do some p2p challenge for your own replies/posts in your community, your replies/community are either 100% spam or 100% curated by the frontend, which will for sure censor you.
the nostr design is fundamentally centralized, they need a p2p fallback for when relays are getting too much traffic, and they need a way to do p2p replies challenges. otherwise anyone can spam infinite replies to his "hello world" post, making the app unusable.
Bitsocial being fully p2p we solve 2 fundamental problems of nostr: 1. relays are not free, they dont scale infinitely unlike P2P. 2. there's no censorship resistant way to moderate/curate replies or posts in a community using nostr.
Neither these things can easily be added to nostr. They could technically be added but it'd be like recoding IPFS/libp2p gossipsub from scratch.
I actually like the spirit of nostr, I just think the technical design doesn't really make sense and would be really difficult to fix, you'd have to add a complete P2P stack to it. if the nostr design allowed censorship resistant infintely scalable social media I would much rather use it than build my own.

2026-05-07 11:47:57 CEST

- reply

if you own the community you can do anything like allowing or forbidding base64 arbitrary data in your own community. But by default we limit all comments to 40kb.
We use IPFS because its the best framework for a global content-addressable p2p network, they also have IPNS (mutable names) which is the basis of our protocol community names. We dont use any DNS/TLS within our core protocol, everything is signed and verified by using IPFS and IPNS primitives.
More info about IPNS here, https://docs.ipfs.tech/concepts/ipns/#mutability-in-ipfs

2026-05-07 11:20:03 CEST

- reply

You can add arbitary data as files to IPFS, and then add their CID as a field to your json. Then peers in the network can decide whether to fetch that CID or not

2026-05-07 07:25:38 CEST

- reply

Sure, thats basically the core thesis behind our project is that DNS is not reliable nor censorship resistant enough for decentralized social media. We do use domains but we use ENS for those and its completely opt-in, you can have a fully running community with people posting to only public key.
More on it here, https://github.com/bitsocialnet/bso-resolver

2026-05-07 02:44:31 CEST

- reply

Bitsocial as a protocol is text only and does not store images. It only stores links. You can embed links within posts in 5chan.app, but you can't upload within the UI unfortunately
But in the mobile/desktop app you can upload images because in the background it uploads to image hosting services like imgur, or imgbb. We can't do that in the browser cause of CORS.

2026-05-07 02:40:20 CEST

- reply

we use IPFS for our p2p backend, more info here. https://bitsocial.net/docs/peer-to-peer-protocol/
Additionally if u go to p2p.5chan.app it will spawn a "light p2p" node that downloads and publishes using websockets to peers directly, although it can't upload anything so it stays a "leech"

2026-05-07 02:34:51 CEST

- reply

Yes Seedit still needs some work. You can look at the "Call to Action" section on the website it explains why the focus is on 5chan right now

2026-05-06 15:08:37 CEST

- reply

Team is here, https://bitsocial.net/about

2026-05-06 14:37:07 CEST

- reply

Thanks for sharing! Let me know if u have any questions about the protocol

2026-05-06 14:30:16 CEST

- reply

except Bitsocial works perfectly while being a P2P system where all nodes are equal to each other, in contrast to nostr where the relay you choose to use affect how many people you can reach

2026-05-06 14:24:47 CEST

- reply

all Bitsocial apps are working perfectly in Safari

2026-05-06 14:24:14 CEST

- reply

Soon! Our docs are being worked on but feel free to read, https://bitsocial.net/docs/peer-to-peer-protocol/

2026-05-06 14:22:38 CEST

- reply

>"only preserve what people actually care about" thing by default
So in Bitsocial communities only maintain the last state they have, and much like Bittorrent if all nodes including the community node dont provide the content nobody will be able to reach it and it will die.
That will be solved eventually with opt-in public RPCs services where people can delegate their communities to be ran to services instead of locally on their own machines. But thats in the future, and currently in the desktop apps everything is pure p2p with no intermediaries

2026-05-06 14:19:56 CEST

- reply

Thing is I'm not sure how will you be able to have full P2P nostr without relays indexing the whole network like it does now. Bitsocial solves this by using cheap http routers, very similar to bittorrent trackers. Then peers can find each other by hashes and connect to exchange content and publish to each other.
Feel free to ask me more about Bitsocial. Our docs is still pretty rough but its worth a read,
https://bitsocial.net/docs/peer-to-peer-protocol/

2026-05-06 14:17:41 CEST

- reply

we do have an android app though, check releases of 5chan and seedit.
Btw try out p2p.5chan.app, full p2p experience in browser with helia/libp2pjs! No more IPFS gateways

2026-05-06 14:15:22 CEST

- reply

Bitsocial Forge Inc doesnt own anything. In the future it will own public RPCs for people who want to delegate running communities to a third party.
All of the project is GPL 3.0 as you can see on github

2026-05-06 14:13:09 CEST

- reply

what apps didn't work? 5chan.app should work, but its still under testing. If you download the desktop app the experience is usually more stable since desktop apps use tcp+quic transports

2026-05-06 14:11:43 CEST

- reply

No need to install http routers, that would be like needing to install bittorrent trackers to use qbittorrent. Just pick any Bitsocial app (I recommend 5chan) and its desktop app would have p2p experience right out of the box.
Also, 5chan is not a centrally hosted web UI. There's multiple mirrors you can pick, and you can also run it locally through either:
- Downloading bitsocial-cli
- Downloading 5chan desktop app / android app
the p2p/pubsub is already included as a dependency by using the library pkc-js, https://github.com/pkcprotocol/pkc-js
Additionally you can also publish and fetch content with full P2P experience using p2p.5chan.app
Read more about it here, https://bitsocial.net/docs/peer-to-peer-protocol/

2026-05-06 14:02:53 CEST

- reply

Protocol cofounder here, whats stupid about it? Would love some constructive criticism