Jonline Server CI/CD Badge gRPC Docs!

Jonline.io BullCity.social OakCity.social ATO.band

Homebrew Linux

DockerHub Server Images DockerHub Preview Generator Images

Jonline is an open-source, community-scale social network designed to be capable of "dumfederating" with other Jonline instances/communities, making sharing between local-size instances easy. All web-facing features in Jonline - the Elm app, Tamagui/React app, the Flutter app, and Media endpoints - are written with easy-to-read AGPL code, localStorage (or system storage, for native Flutter apps), and neither set nor read cookies at all, ever. Thus, an unmodified Jonline server shouldn't need a cookie notice under the GDPR or CCPA. Moreover, any modified version of Jonline that does use cookies would violate the AGPL if the source weren't provided to users.

Meanwhile, in support of media creators/providers who might want to self-host Jonline for themselves or in a consortium (whether in lieu of or in addition to monolithic social media presence like YouTube or Twitch), Jonline's CORS support does still afford private media holders a basic way to control who can see their content. Further, better Media permission/visibility controls could definitely be added, should, say, video creators or streamers want to migrate to self-hosting using a Jonline instance as their decentralized video platform to charge for premium content.

The "dev" instance is up at Jonline.io. Three "production" instances are also at BullCity.Social, OakCity.Social, and ATO.Band. Unless I'm doing some testing with Jonline.io, all three should be configured to be able to federate with one another (or, for clients to federate between them). For anyone curious, all three (along with their corresponding Postgres and MinIO) live on a single-box DigitalOcean K8s instance. Between the 3 Load Balancers, storage, and compute resources, it costs about $60/mo to run the 3 domains, though that cost can be brought closer to $40/mo. (All also keep their media and HTML/CSS/JS behind Cloudflare's free CDN.)

Buy me a coffee! Buy me a beer!

Packages, Images & Deployments

Jonline can be run from source, via Homebrew, with a Linux binary package, or with Docker images.

At a high level, Jonline's CI/CD (example run) is setup to do the following, stopping if there are issues:

  1. Build and test the Rust BE, Elm FE and Tamagui/React FE.
  2. Build a server Docker image and deploy it to jonline.io.
    • The Docker images are minimal Debian images with a jonline server binary, as well as binaries for various jobs, used for the live deployments currently at jonline.io, bullcity.social, and oakcity.social. Environment variables allow fairly straightforward configuration with Kubernetes.
  3. Create a GitHub Release.
  4. Create Homebrew & Linux packages, and deploy to bullcity.social and oakcity.social.
    • The Homebrew/Linux jonline is actually a platform-specific, bash-based "thin launcher.
      • The bash-based jonline launcher provides tools for running the server, jobs, and admin tasks.
      • Homebrew/Linux rename the Rust jonline server binary to jonline-server (macOS) and jonline-server-[arm64|amd64] (Linux).
      • The launcher runs everything from an "install directory" which also contains the frontends (/#{etc}/jonline/ for Homebrew, your extracted test directory or ~/.jonline-linux/ for the Linux package).
      • The Linux/macOS launchers store environment variables in ~/.jonline and load them before starting the server or other services.

macOS: Install and Run via Homebrew

The Homebrew distro puts the Jonline server contents in /#{etc}/jonline, with a bash-based thin launcher for it at #{bin}/jonline. The launcher can set up your local Postgres DB with createdb and dropdb for you, and start a MinIO instance with docker. You will need to provide these yourself, but that's it.

Additional docs for the Jonline thin launcher can be found in docs/homebrew_jonline.sh (which is literally the launcher script that will become your #{bin}/jonline, if you wanna PR any changes).

2 minute startup with Homebrew

Prerequisites for your $PATH:

brew install jonlatane/jonline/jonline

jonline help # show subcommands for the bash launcher

# Either configure to use your own MinIO/Postgres (and thus not needing `createdb` or `docker`):
jonline environment # literally just: cat ~/.jonline. Contains database, MinIO, and optional TLS credentials.
jonline edit_environment # literally just: $EDITOR ~/.jonline. Edit those database, MinIO, and optional TLS 

# Or, create the examples. These are what will be auto-populated in ~/.jonline.
jonline local_db_create # Requires a local Postgres instance. literally just: createdb jonline_dev
jonline local_minio_start # literally "just": docker start jonline-dev-minio || docker run -d -p 9000:9000 -p 9090:9090 --name jonline-dev-minio -v $(MAKEFILE_DIR)/.minio-data:/data -e "MINIO_ROOT_USER=ROOTNAME" -e "MINIO_ROOT_PASSWORD=CHANGEME123" minio/minio server /data --console-address ":9090"credentials.

# Launch the server (and its background jobs). HTTP on ports 80 and 8000, 27707 (gRPC), and HTTPS on 443 if TLS is configured.
jonline server_and_jobs

# Once the server is running (presumably in another tab, or the background, or a daemon),
# you can set up an admin user.
open http://localhost/

# In your browser, create a user account and remember your username.
# To give them admin permissions:
jonline set_permission my_admin_username admin on

brew upgrade jonlatane/jonline/jonline # Upgrade to the latest release.

Linux: Self-updateable .tar.bz2 with arm64 and amd64 binaries and launcher

Rather than figure out all the Linux repos' stuff, Jonline ships as Linux tarball with both arm64 and amd64 binaries, and a launcher (mirroring the Homebrew one) to choose the right archicture's binaries. It can also auto-delete unneeded binaries. You can run Jonline from either wherever you extract it, or install it to ~/.jonline-linux/ (which, along with the platform-agnostic env vars in ~/.jonline, and any $PATH-setting you do yourself, are its only traces on your system).

Additional docs for the Jonline thin launcher can be found in docs/linux_jonline.sh (which is literally the launcher script that will become your #{install_dir}/bin/jonline, if you wanna PR any changes).

Unlike the Homebrew distro, this is straight up untested by me. So please, submit issues or PRs.

3 minute startup on Linux

Prerequisites for your $PATH:

# Get the package with curl/jq, and extract it. This is actually also what updater script does.
curl -s https://api.github.com/repos/jonlatane/jonline/releases/latest \
  | jq -r '.assets[] | select(.name | test("-linux\\.tar\\.bz2$")) | .browser_download_url' \
  | xargs curl -L -o jonline.tar.bz2
mkdir jonline && tar xjf jonline.tar.bz2 -C jonline && rm jonline.tar.bz2
cd jonline
./bin/jonline version

# Either just do this to run from wherever you extracted it:
export PATH=$PATH:$(pwd)/bin

# Or, to install to $HOME/.jonline-linux immediately:
./bin/jonline install
    # If you choose to install, this to might be also useful to add to your .profile/.zshrc/etc.:
    export PATH=$PATH:$HOME/.jonline-linux/bin

# Optional: tab-completion for jonline subcommands. Homebrew wires this up automatically;
# on Linux there's no package manager to hook into, so add ONE of these to your shell
# startup file yourself (works whether or not you ran `jonline install` above):
echo 'eval "$(jonline completion bash)"' >> ~/.bashrc   # bash
echo 'eval "$(jonline completion zsh)"' >> ~/.zshrc     # zsh

### The rest of setup is the same as for macOS:

jonline help # show subcommands for the bash launcher

# Either configure to use your own MinIO/Postgres (and thus not needing `createdb` or `docker`):
jonline environment # literally just: cat ~/.jonline. Contains database, MinIO, and optional TLS credentials.
jonline edit_environment # literally just: $EDITOR ~/.jonline. Edit those database, MinIO, and optional TLS 

# Or, create the examples. These are what will be auto-populated in ~/.jonline.
jonline local_db_create # Requires a local Postgres instance. literally just: createdb jonline_dev
jonline local_minio_start # literally "just": docker start jonline-dev-minio || docker run -d -p 9000:9000 -p 9090:9090 --name jonline-dev-minio -v $(MAKEFILE_DIR)/.minio-data:/data -e "MINIO_ROOT_USER=ROOTNAME" -e "MINIO_ROOT_PASSWORD=CHANGEME123" minio/minio server /data --console-address ":9090"credentials.

# Launch the server (and its background jobs). HTTP on ports 80 and 8000, 27707 (gRPC), and HTTPS on 443 if TLS is configured.
jonline server_and_jobs

# Once the server is running (presumably in another tab, or the background, or a daemon),
# you can set up an admin user.
xdg-open http://localhost/

# In your browser, create a user account and remember your username.
# To give them admin permissions:
jonline set_permission my_admin_username admin on

Install/self-update on Linux

Whereas Homebrew gives you updates via brew, the Linux version ships with an update script, again, a vibe-coded blend of curl and jq. Once you've gotten things running via the above guide, you may want to install. All these commands are just a bash script you can/should look at before running them.

# If you want to self-update, you may want to:
jonline install # OPTIONAL. Copies your `jonline` directory to `~/.jonline-linux` Everything but "jonline update" works without installing.
jonline show_latest # Show the latest available release from GitHub.
jonline update # Updates you to the latest jonline release from GitHub.

# If you want to delete ~/.jonline and ~/.jonline-linux, you can always:
jonline uninstall

DockerHub: Server and Preview Generator images

Jonline has an intuitive (helm-less) mechanism and conventions for templating Jonline server/Postgres/MinIO containers into Kubernetes namespaces. Helm-ification or other improvements, if "friendlily" documented, are very welcome.

DockerHub Server Images DockerHub Preview Generator Images

Live (DigitalOcean Kubernetes/DOKS) deployments

Jonline's CI is set up to deploy the above Docker images as part of its build system. (In fact, it won't cut its GitHub/Homebrew/Linux releases until it deploys a canary build to jonline.io.)

To set up a deployment yourself, see: Quick deploy to your own cluster.

Deployment Purpose Federation Settings Links Deployment Version
Jonline.io Jonline.io Flagship demo/informational site BullCity.Social (pinned), OakCity.Social (pinned) About, Elm UI, Tamagui/React UI, Protocol Docs Development/Canary
BullCity.Social BullCity.Social Durham, NC Community Page OakCity.Social (pinned) About, Elm UI, Tamagui/React UI, Protocol Docs Production
OakCity.Social OakCity.Social Raleigh, NC Community Page BullCity.Social (pinned) About, Elm UI, Tamagui/React UI, Protocol Docs Production
ATO.Band ato.band Site for my band, Against The Odds BullCity.Social (pinned) About, Elm UI, Tamagui/React UI, Protocol Docs Production

What is Jonline?

Broadly speaking, Jonline is something of an "internet philosophy." It's my (Jon's) philosophy. It's a generally anti-capitalist tech approach that has a few perhaps obvious opinions on everything from user data privacy expectations, to cost of servers, through CI/CD, the BE, API design, user expectations for transparent permissions/moderation/visibility on things like People, Media, Groups, Posts, and Events, etc. Conveniently, things that meet my (Jon's) requirements for these these things can be described as "Jonline CI/CD,", "Jonline API Design,", "Jonline Events," and so forth.

As a more traditional market product, Jonline is a network of, and a protocol for, social networks that meets my (Jon's) expectations of usability, transparency, and fairness. It's designed to scale as well as Mastodon or better, but really, it aims to be something more like Plex, but as a social network released under the AGPL (and also, Kubernetes/LetsEncrypt/CertManager-friendly). Use cases include:

The core model of Jonline is that each of these communities is run as its own Jonline instance. Each of these instances and their data are literally owned by the organization (or a chosen "IT admin person" and/or "moderation team" for it). Finally, the same person's accounts on all of these instances can be federated (if the user chooses, and dependent upon server configurations and permissions, of course). Federation is simply a means to let, say, a user, Jeff, see their D&D DM also knows the guy from run club who left his wallet, even if Jeff and the DM are not friends on the run club network, but only if the DM chooses to federate their identity across both those networks.

One way to think of Jonline is as social media meets the email server model (I use Gmail, you use your ISP's email, we can still talk to each other), with a bit of the ListServ model too (it's very easy to set up a neighborhood Jonline instance, Posts function effectively identically to ListServ messages, and Events are basically just a nice extra feature ListServ doesn't have).

Another way to think of Jonline is that it's like Slack or Discord, except instead of messages/channels/voice chats, it's just for Posts and Events. And your Jonline instance is code you can actually see running on equipment you own, not proprietary code running on a corporation's servers.

A core goal is to make Jonline dogshit easy (🐕💩EZ) for anyone else to deploy to any Kubernetes provider of their choosing (and to fork and modify). It's also (optimistically) simple and straightforward enough to serve as a starter for many projects, so long as they retain the AGPL license Jonline is released under. All you need is a Kubernetes (k8s) cluster, git, kubectl, make, and a few minutes to get the prebuilt image up and running. This very document also has instructions for a 2 minute startup with Homebrew and 3 minute startup on Linux.

In a perfect Jonline universe, every local business with a sip 'n' sketch, open mic, trivia night, run/bike club, etc.; every arts council, parks & rec department, library, etc. could run a Jonline instance on their own hardware or from any number of providers (because it's very cheap to host lots of Jonline instances on a cloud, by design) for a cost of $20-50/year from a provider, or for free on their own servers. Members of these communities could sign up only with the ones they want, and view events/posts where they want, when they want. Those community members don't need to share emails or phone numbers to do anything on these communities. Moderation is done by people working at the businesses/organizations. No one can become a billionaire running it, but also, users can participate in all these communities online without their data becoming the property of some billionaire.

Why Jonline vs. Mastodon/OpenSocial?

The goal of all this is to make it as easy as possible for local businesses to:

Jonline as a protocol vs. ActivityPub

Jonline is also a protocol, much like ActivityPub. It's worth skimming both the ActivityPub Protocol Docs and the Jonline Protocol Docs, but this is a brief breakdown.

Notably, while ActivityPub specifies a server-to-server federation protocol, Jonline simply lets servers "recommend" other servers by hostname, with the "federation" done on the client side by communicating with the recommended servers based on user authorization. (Yes, this could barely defined as "federation" at all - but it's cheaper and effectively the same to users. The Jonline protocol simply calls this dumfederation.)

While ActivityPub is defined using HTTP(S) and JSON, Jonline is defined with gRPC (on port 27707, with optional TLS), using HTTP(S) for media and CDN-based host negotiation only (no JSON, anywhere). Broadly speaking, Jonline may be called "more opinionated" than ActivityPub as a social networking protocol, and covers more things than just social activity (including things like user-facing server configuration data, privacy policy, etc.).

Whereas ActivityPub has a flexible Activity model capable of holding varied metadata, Jonline's API definitions deliberately avoid allowing for metadata, and focus on statically-typed, specific models for Posts and Events. The Jonline data model is designed using composition, with Events' titles, descriptions, moderation, etc. belonging to a Post owned by them, over inheritance (i.e. making Event "extend" Post in OOP). Jonline leverages this to implement visibility and moderation controls for Posts and Events across the system all in one place.

In addition to Users, Posts, and Events, which could all be "described" by ActivityPub's specification, Jonline also has Media (designed to leverage external CDNs), Groups, Server Configuration, and moderation/visibility/permission management across everything as a first-class citizen.

The hope is to build more useful business objects - yes, your boring SalesForce/NetSuite/SAP type stuff - into this social protocol. So Jonline Payments, Products, Subscriptions, and who knows what else could, eventually, be gradually implemented atop the Jonline protocol, with all the same clear, concise, documentation, cross-language portability, and other benefits it offers.

All this is to say: it should be pretty straightforward to create, say, Ruby bindings for Jonline, and use them in Mastodon to make it work as a no-Events-support, no-Media-support Jonline instance. Or vice versa. This is back burner research, though. Get in contact if you're interested in contributing/learning to do this type of work!

Why not Jonline?

Features Overview

All of Jonline's features should be pretty familiar to most social media users. Notably, in both its web and Flutter UIs, Jonline is designed to present "My Media" as a top-level feature and let users delete and manage Media visibility independently of Posts, Events, Groups or anything else.

Jonline Identifiers: Usernames, Group Names, and IDs

A key point of contention in the Fediverse is the notion of universal usernames and IDs. Jonline also supports Groups and Group Names (which work much like subreddits or Facebook groups). There's a lot of complex implementations around this in Mastodon and elsewhere. Since Jonline's protocols do not specify anything about server-to-server communication, none of that stuff is really necessary in the Jonline approach at all! At a high level, Jonline Usernames, Group Names, and IDs look like a mix between URLs and email addresses. An important feature of both Jonline Usernames and IDs is that they do not change when URL-encoded.

For instance: I can claim jonline.io/jon, bullcity.social/jon, and oakcity.social/jon for myself. But if you decide to start an instance at febreze.lol/jon and I want to make an account and share with you (I absolutely would!), I'll just have to register as febreze.lol/jonline-jon or my username of choice to interact on there. (But, in the future, I will be able to interlink all 4 of these profiles to make them appear as verified alternate identities across the servers!)

Jonline Usernames are, essentially, a link to a profile. Jonline gives the top-level resource names to users; i.e., user bob123 on jonline.io can be found at jonline.io/bob123. Users can change their usernames, but User IDs are permanent (unless the server administration changes the ID offset; see below for details.) The few usernames you can't use on Jonline are enumerated in this Rust source.

Example Jonline usernames:

Jonline Group Names work much like usernames, but for groups. They are automatically derived from the actual group name (they are the field Group.shortname, derived from Group.name by removing non-word characters).

Example Jonline Group Names:

Jonline IDs are numerical IDs for any entity type on a server. We might say: in the context of Jonline.io, Post ID T6S8eoDmmtb would be expected to be found at jonline.io/post/T6S8eoDmmtb. (Note that the numerical portion of the ID is literally just a 64-bit integer encoded with base58 and a server-configurable offset. The best reference for how "Jonline ID Marshaling" works would be these <90 lines, including test coverage, of Rust code.)

Example Jonline IDs:

People, Followers and Friends

Jonline allows users to create accounts and login with nothing but a username/password combo. Anyone can Follow anyone, but users can require approval for Follow Requests. Two users who Follow each other are Friends.

Groups and Memberships

Jonline supports Groups, which are much like Usenet groups, Facebook groups, or subreddits.

Media

Jonline Media is something like ActiveStorage, but with Rust and Diesel. It's straightforwardly built on content-types and blob storage. It's the reason Jonline requires S3/MinIO. Unlike Posts and Events, Media is generally not shared directly. It is instead associated with Posts and Events (for media listings) as well as Users and Groups (for their avatars).

Media is the only part of Jonline's APIs offered over HTTP as well as gRPC/gRPC-over-HTTP. (Hopefully the reasons for this are obvious: easy browser streaming and cache utilization for things like images.) Details on the HTTP Media APIs are in the "Media" section of the protocol documentation.

All Media also carries Visibility and Moderation values that can be modified in the APIs, but are not currently enforced. Note that any Media visibility updates and/or deletions may take time to propagate fully, depending upon how a given Jonline instance's CDN setup works.

Posts

Posts follow a Twitter- or Reddit- like model. They have a PostContext as well as all-optional title, link, and description string values. A top-level post is stored generally the same as a reply. Posts also carry a Visibility and Moderation value that is enforced by the APIs.

Posts are also reused for Events, and will be similarly reused for future features. For developers: this is something like ActiveRecord Polymorphism, but using composition rather than inheritance at the ORM level. For users: Replies, Events, and other Jonline types track their title, description, visibility, moderation, etc. via a Post internally.

GroupPost

A key differentiator between Post and Media is that Posts and types that use them are "group-aware." That is to say: GroupPost exists, linking any unique Group to any unique Post, along with the User who created that link.

Events

Events are a thin layer atop Posts. Any Event has a single Post, as well as at least one EventInstance. An EventInstance has a start time, end time, location, and RSVP/attendance data. Group Events work through the GroupPost mechanism.

Potential future features

If you want these features prioritized, or have ideas about how they would fit into Jonline's design philosophy, reach out to me in any way, but especially with those payment buttons above 🙏

Dumfederation

A key thing that separates Jonline from Mastodon and other Fediverse projects is that it does not support server-to-server communication. Essentially, the only server-to-server communication supported is via protocol-defined federated servers, allowing, for instance, jonline.io's UI to automatcally integrate posts and events from bullcity.social and oakcity.social. (To limit this sort of external access, bullcity.social and oakcity.social admins can always use CORS.)

Similarly, the protocol supports federated profiles that allow, e.g., my profile at jonline.io/jon to automatcally integrate information from other profiles at bullcity.social/jon and oakcity.social/jon.

This approach does not seek to be particularly innovative or groundbreaking technologically. It simply aims to make it easier for people to use existing web standards to interact, share, plan, and play with each other, and make administrating a server simple enough that nearly anyone can do it. All you need to worry about as an administrator in this regard is a list of servers like this - literally nothing but a list of hosts.

Protocol Documentation

A benefit of being built with gRPC is that Jonline's generated Markdown documentation is relatively easy to read and complete. Jonline renders documentation as Markdown, and converts that Markdown to HTML with a separate tool. Jonline servers also always include a copy of their own protocol documentation (i.e., https://jonline.io/docs/protocol, https://bullcity.social/docs/protocol, and https://oakcity.social/docs/protocol).

Project Components

The following components are literally just a "nice to read" breakdown of the overall directory structure of this repository. Nonetheless, this should be a useful first pass for anyone hoping to contribute to Jonline.

Documentation

Yes, even Jonline's documentation is documented! 😅

Jonline documentation consists of Markdown in the docs/ directory, starting from docs/README.md.

The Documentation root is in docs/. Note that docs/protocol.md is generated from the gRPC APIs, and docs/protocol.html is generated from docs/protocol.md (to make the generated HTML as friendly as possible).

Additionally, the following components are themselves documented in README.md files that follow Jonline's project component structure:

gRPC APIs

The gRPC APIs are defined in protos/.

Architecture/Deployment Management

Jonline architecture docs live in docs/architecture.

At its core, Jonline is a boring client-server app; the Browser/App, HTTP server, gRPC server, PostgreSQL, and MinIO interact thusly:

Jonline Application Architecture

Generally, Jonline is designed to be straightforward to deploy to Kubernetes clusters so long as you have make, kubectl, and jq. To this end, Jonline has a "simple" deployment structure, and a more scalable alternative using Traefik:

Simple Approach Scalable Approach
K8s cluster with multiple Jonline Kubernetes LoadBalancers K8s with single Trafik LoadBalancer
See deploys/ingress/README.md for details.

Jonline's architecture docs also cover and link to such topics as:

CI/CD logic is defined in .github/workflows/. If you can set up a Kubernetes deployment with the instructions in deploys/, it should be straightforward to integrate your own CI into

Rust Backend

The Rust backend, in backend/, is built with Diesel and Tonic.

Frontends

Jonline Frontends are grouped together in frontends/. Specific iOS, Android, and/or desktop frontends would be welcome contributions!

Elm Frontend

The Elm frontend, in frontends/elm-spa, is the new "public Web face" of any Jonline instance. It's built with Elm and Elm-Spa.

Web (Tamagui/React/Next.js) Frontend

The Tamagui frontend, in frontends/tamagui, was, until recently, the "public Web face" of any Jonline instance. It's the most "complete" UI, and some features can still only be edited in this UI. It's built with Tamagui (a somewhat Flutter-like UI toolkit and build system built atop yarn, React, React Native, and Next.JS), along with Redux among others.

Notably, in the future, with Tamagui, it should be possible to build iOS/Android apps from the existing Jonline source (after some effort to port less-native-friendly third-party components).

Flutter Frontend (Deprecated/To Be Deleted Unless A Contributor Fixes It)

The Flutter frontend is deprecated, unless someone would like to maintain it. It's just not feasible to maintain a Flutter app long-term, IMO. I love the UI framework but its ecosystem changes rapidly underneath you as a developer. It's removed from CI/CD, including the server. At some point it will be deleted from the repo entirely.

The Flutter frontend, in frontends/flutter, is built with vanilla Flutter, Provider, auto_route, and protoc_plugin, among others.

Quick deploy to your own cluster

If you have kubectl and make, you can be setup in a few minutes. (If you're looking for a quick, fairly priced, scalable Kubernetes host, I recommend DigitalOcean.) First make sure kubectl is setup correctly and your instance has the jonline namespace available with kubectl get services and kubectl get namespace jonline:

$ kubectl get services
NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   10.245.0.1   <none>        443/TCP   161d
# You should not be using a Kubernetes namespace named jonline; otherwise, existing services could be overridden.
$ kubectl get namespace jonline
Error from server (NotFound): namespaces "jonline" not found

To begin setup, first clone this repo:

git clone https://github.com/JonLatane/jonline.git
cd jonline

Next, from the repo root, to create Postgres, Minio and two load-balanced Jonline servers in the namespace jonline (plus a few recurring jobs), run:

# THIS STEP WILL COST MONEY WITH MOST KUBERNETES PROVIDERS. ($12/mo. at DigitalOcean)
# The create_external_backend Make target, specifically, will create the Joline service as a K8s LoadBalancer.
# Of course, it costs nothing to use Minikube.
# To deploy for use with a different ingress (say, a shared nginx, or Jonline's pending internal LB), use create_internal_backend or deploy_be_internal_insecure_create to deploy it as a K8s ClusterIP instead.
make create_backend_data create_external_backend

That's it! You've created Minio and Postgres servers along with an unsecured Jonline instance where passwords and auth tokens will be sent in plain text (You should secure it immediately if you care about any data/people, but feel free to play around with it until you do! Simply make delete_backend_data create_backend_data restart_backend to reset your server's data.) Because Jonline is a very tiny Rust service, it will all be up within seconds. Your Kubenetes provider will probably take some time to assign you an IP, though.

Simply kubectl delete namespace jonline to delete your deployment (or see below for more detailed management instructions).

Deployment management: domains and TLS certs; deploying multiple jonline instances to different K8s namespaces in the same cluster; and cross-namespace load balancing with Traefik

deploys/Makefile, deploys/generated_certs/Makefile, and a few of Jonline's Rust binaries (mostly the main jonline server) provide the tools to update your deployment, point a domain at it, manage TLS certificates, and more.

For details on these scenarios and more when deploying to your own cluster, see deploys/README.md, deploys/generated_certs/README.md, and deploys/ingress/README.md.

Motivations

Signal is really good for private communication and group chats. However, we need something like this for public community organizing, and really alternative social media in general. In my opinion, ActivityPub and ATProto are at the same time limited in terms of actual social management features, outright bad at events management, and they're badly documented and unclear APIs. Jonline seeks to be a very pragmatic Reddit/Twitter/Usenet/Facebook Events hybrid that doesn't do algorithmic rankings at all.

Most of all, though, I'd just really be happy if using Jonline for your community brought you some joy.