Where can I find the protocol specifications?

Partially.

Great question! Unlike Lemmy, which relies on federation with dedicated servers, Plebbit is fully peer-to-peer (P2P) and does not have a central server or even instances. Instead, storage happens via a combination of IPFS and users seeding data. Here’s how it works:

Where Is Plebbit’s Data Stored?

1. Subplebbit Owners Host the Data (Like Torrent Seeders)

   • Each subplebbit owner runs a Plebbit node that stores and republishes their own community’s data.
   • Their device (or a server, if they choose) must be online 24/7 to ensure the subplebbit remains accessible.
   • If a subplebbit owner goes offline, their community disappears unless others seed it—very similar to how torrents work.

2. Users Act as Temporary Seeders

   • Any user who visits a subplebbit automatically stores and seeds the content they read.
   • This means active users help distribute content, like in BitTorrent.
   • If a user closes their app and no one else is seeding the content, it becomes unavailable until the owner comes back online.

3. IPFS for Content Addressing

   • Posts and comments are stored in IPFS, which ensures that popular content remains available longer.
   • Unlike a blockchain, there is no permanent historical ledger—if no one is seeding, the data is gone.
   • Each post has a content address (CID), meaning that as long as someone has the data, it can be re-fetched.

4. PubSub for Live Updates

   • Plebbit uses peer-to-peer pubsub (publish-subscribe messaging) to broadcast new content between nodes in real-time.
   • This helps users see new posts without needing a central server to pull updates from.

What Happens If Everyone Goes Offline?

• If no one’s online to seed a subplebbit, it’s as if it never existed.
• This is a trade-off for infinite scalability—it removes the need for central databases but relies on community participation.
• Think of it like a dead torrent—no seeders, no content.

Comparison With Lemmy

Bottom Line: No Servers, Just Users

• With Lemmy: The instance owner has to host everything themselves like a mini-Reddit admin.
• With Plebbit: The subplebbit owner AND users seed the content—no one has to host a centralized database.
• If something is popular, it stays alive.
• If something isn’t seeded, it disappears, just like torrents.

It’s a radical trade-off for decentralization and censorship resistance, but if no one cares about a community, the content naturally dies off. No server, no mods deleting you from a database—just pure P2P.

Hope that clears it up! 🚀

Plebbit only hosts text. Images from google and other sites can be linked/embedded in posts. This fixes the issue of hosting any nefarious content.

Nowhere in the project whitepaper or FAQ does it talk about banning image hosting. Base64 encoding images in the text post is trivial, so maybe OP is the one projecting this intent or feature?

No judgement here. I think it’s a worthy goal just not one I am particularly interested in at this point. Maybe if the automation was a bit easier and the mobile device management was easier I might join you.

My experience is it’s really a lot of work and with the prevalence of letsencrypt, there is not a lot of automated setups for this use case (at least that I have been able to find). It is kind of a pain in the ass to run your own CA, especially if you plan to not use wildcard and to rotate certs often. If you use tailscale, they offer https certs with a subdomain given to you:

[server-name].[tailnet-name].ts.net

That’s honestly what I’m moving towards.

Another vote for wiki.js. It has tons of authentication options and integrations. The mobile web interface is a tad clunky but usable.

Since you brought it up, what is the difference there? Do you mean gameplay design as in the whole game is this way or as in this scene is not a level? (No I didn’t watch OP’s video.)

The factory must grow

I see. GP said the same. Thanks for sharing!

True enough for VNC but we’re specifically talking about RDP, which is supported by Linux Mint.

Yea that looks pretty amazing. Thanks for sharing!

Single node k3s is possible and can do what you’re asking but has some overhead (hence your acknowledgment of overkill). One thing i think it gets right and would help here is the reverse proxy service. It’s essentially a single entity with configuration of all of your endpoints in it. It’s managed programmatically so additions or changes are not needed to he done by hand. It sounds like you need a reverse proxy to terminate the TLS then ingress objects defined to route to individual containers/pods. If you try for multiple reverse proxies you will have a bad time managing all of that overhead. I strongly recommend going for a single reverse proxy setup unless you can automate the multiple proxies setup.

And here I am running a bare metal k3s cluster fully managed by custom ansible playbooks with my templatized custom manifests. I definitely learned a lot going that way. This project looks like it has just about everything covered except high availability or redundancy, but maybe I missed it in the readme. Good work but definitely not for me.

Sounds like a good option then!

Yep that’s why I use KDE. It has nVidia support for Wayland.

I have heard they are either working on a similar thing for Wayland or already solved it.

This looks promising, but I have not used it before.

waypipe is a proxy for Wayland[0] clients. It forwards Wayland messages and serializes changes to shared memory buffers over a single socket. This makes application forwarding similar to ssh -X [1] feasible.

[0] https://wayland.freedesktop.org/ [1] https://wiki.archlinux.org/title/OpenSSH#X11_forwarding

Check out Termux. It lets you install nearly any linux software on your Android device. Probably a good place to start to get your toes wet.

I’ve used X11 over SSH before and it works great for some use cases, however it does not work with Wayland, so if their system supports it now, there’s no guarantee it will work after a major system update.

In my experience, RDP locks the screen for anyone at the physical machine. It sounds like OP is wanting a simultaneous screen sharing.