Subspace

Warning

This project was almost entirely vibe-coded. It's intended to provide the bare-minimum functionality to begin a transition from Discord. I don't recommend using this in any situation. If for some reason you do, only allow access to the server to people you know personally, as there are severe security implications. For example, the /upload endpoint was vibe-given public access by Claude. Lmao. I'm not a security expert, so take this with a grain of salt. Hey, at least I wrote the README 🤷

Subspace is a discord-like messaging application that is intended to provide the bare-minimum functionality to get orphans from Discord off the ground without requiring too much complicated setup.

As long as you can host a server or docker container on a computer somewhere, you can host your own subspace server.

The gist

Client and server downloads are available on the releases page.

• Host the backend server (available as a docker container) on a particular IP, ideally behind a reverse-proxy like nginx or cloudflared
• Clients can download the client for their platform and enter the IP of your main server.
• The client will remember this IP, and provide a discord-like interface for managing and connecting to servers.

Running locally

# Install dependencies
npm install

# Run the server
cargo run -p server

# Run the client
npm run tauri dev

Detailed Hosting Instructions

Docker Compose

The easiest way to host Subspace is via Docker. Create a docker-compose.yml file with the following configuration:

services:
  subspace:
    image: winzlebee/subspace:latest
    ports:
      - "8080:8080"
    volumes:
      - ./data:/app/data
    restart: always

Run the server:

docker compose up -d

Reverse Proxy (Nginx)

Since Subspace uses WebSockets, your reverse proxy must be configured to handle connection upgrades.

server {
    listen 80;
    server_name your.domain.com;

    location / {
        proxy_pass http://localhost:8080;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
    }
}

Configuration

The configuration file for the server is generated on first run, and is located at data/config.toml.

LetMeIn

To restrict access, the [letmein] section is automatically configured with enabled = true on first run. This is critical for security as mentioned in the warnings above.

To begin with, this means nobody can join the server. Not even you. You can add yourself to the list of instance administrators after registering under the instance_admins = [] field in the config file. Note that this takes UUID strings, not usernames. You can find your UUID in your user settings.

As users join the server, they'll initially get a message saying that they're not allowed in and to wait for 'someone' to let them in. They can be let in by an instance admin using the 'Let Me In' button in the instance admin panel under 'Users waiting to get let in', which is only visible to instance admins. Before they do this, the user will be unable to do anything and we'll reject any API call they try to make.

If you'd like anyone to be able to connect to the server Not recommended, you can set enabled = false in the config file. The entire letmein system will be disabled, and anyone will be able to register to join the server.

Technologies and Notes

Not that it really matters (what - with it being vibe-coded and all), but here's what I told the LLM to use:

• Client: Tauri - using Svelte, TailwindCSS, DaisyUI It didn't really like using DaisyUI sometimes and just rolled-its-own using raw-dog TailwindCSS. Ah well. For example, I would have liked for it to use all of DaisyUI's avatar components.
• Server: Rust - using Tokio, WebRTC, SQLite The server was pretty much a one-shot affair, kinda impressing me in the process. It won't handle many, many users very well, mostly because of the Sqlite backend, but it's fine for now.

Limitations

A lot at the moment. The ones that I plan to maybe plug away at;

• Only sqlite is supported as a database backend at the moment. This limits this to smaller servers, as that's all I needed to get running.
• No video and screenshare is available

Contributing

I'm not really expecting anyone to contribute to this, but if you'd like to, feel free to open a pull request. I'm not really sure what I'm doing, so I'm open to suggestions. I'm not a security expert, so if you see any security issues, please let me know.