μpub

micro social network, federated

• about
  • features
  • security
  • caching
• deploy
  • install
  • run
  • configure
• development
  • contacts
  • contributing

about

μpub aims to be a private, lightweight, modular and secure ActivityPub server

μpub is modeled around timelines but tries to be unopinionated in its implementation, allowing representing multiple different fediverse "modalities" together

all client interactions happen with ActivityPub's client-server methods (basically POST your activities to your outbox), with appropriate extensions: μpub doesn't want to invent another API!

Note

a test instance is available at dev.upub.social

features

μpub boasts both known features and new experimental ideas:

• quote posts, groups,
• media proxy: minimal local storage impact
• AP explorer: navigate underlying AP documents
• on-demand thread fetching: get missing remote replies on-demand
• granular activity privacy: control who gets to see each of your likes and shares
• actor liked feeds: browse all publicly likes content from users, as "curated timelines"

security

most activitypub implementations don't really validate fetches: knowing an activity/object id will allow anyone to resolve it on most fedi software. this is of course unacceptable: "security through obscurity" just doesn't work

μpub correctly and rigorously implements and enforces access control on each object based on its addressing

Warning

most instances will have "authorized fetch" which kind of makes the issue less bad, but anyone can host an actor, have any server download their pubkey and then start fetching

μpub may be considered to have "authorized fetch" permanently on, except it depends on each post:

• all posts marked public (meaning, addressed to https://www.w3.org/ns/activitystreams#Public), will be fetchable without any authorization
• all posts not public will require explicit addressing and authentication: for example if post A is addressed to example.net/actor
  • anonymous fetchers will receive 404 on GET /posts/A
  • local users must authenticate and will be given said post only if it's addressed to them
  • remote servers will be given access to all posts from any of their users once they have authenticated themselves (with http signing)

Important

note that followers get expanded: addressing to example.net/actor/followers will address to anyone following actor that the server knows of, at that time

caching

μpub doesn't download remote media to both minimize local resources requirement and avoid storing media that remotes want gone. to prevent leaking local user ip addresses, all media links are cloaked and proxied.

while this just works for small instances, larger servers should set up aggressive caching on /proxy/... path: more info in coming sections

deploy

μpub is built with the needs of small deployments in mind: getting a dev instance up is as easy as running one command, and setting up for production just requires some config tweaking

install

Caution

official releases are being automated, available very soon

latest μpub build can be downloaded from [moonlit.technology releases page](todo add link!!)

$ curl -s https://moonlit.technology/alemi/upub/releases/.... > upub; chmod +x upub

Important

automated builds by GitHub are planned and will follow

from source

building μpub from source is also possible without too much effort. it will also allow to customize the resulting binary to your specific use case

if you just want to build the backend (or some of its components), a simple $ cargo build will do

---

to also build upub-web, some extra tooling must be installed:

• rust wasm32-unknown-unknown target ($ rustup target add wasm32-unknown-unknown)
• wasm-bindgen ($ cargo install wasm-bindgen-cli)
• trunk ($ cargo install trunk)

from inside web project directory, run trunk build --release. once it finishes, a dist directory should appear inside web project. it is now possible to build μpub with the web feature flag enabled, which will include upub-web frontend

cd web
trunk build --release
cd ..
cargo build --release --features=web

run

μpub includes its maintenance tooling and different operation modes, all documented in its extensive command line interface.

Tip

make sure to use --help if you're lost! subcommands have different help screens

all modes share -c, --db and --domain options, which will set respectively config path, database connection string and instance domain url

neither is necessary: by default a sqlite database upub.db will be created in current directory, default config will be used and domain will be a localhost http url

there is no default config path: point explicitly with -c flag

bring up a complete instance with monolith mode: $ upub monolith

to view μpub full default config, use $ upub config

most maintenance tasks can be done with $ upub cli

---

a proper deployment will require:

• a migrated database (run $ upub migrate --db <your-db-connection-string> once)
• core activitypub routes (feature flag routes, cli $ upub serve)
• a job worker (feature flag worker, cli $ upub work)

running $ upub monolith will do all of these

configure

media proxy cache

caching proxied media is quite important for performance, as it keeps proxying load away from μpub itself

for example, caching nginx could be achieved this way:

proxy_cache_path /tmp/upub/cache levels=1:2 keys_zone=upub_cache:100m max_size=50g inactive=168h use_temp_path=off;

server {
	location /proxy/ {
		# use our configured cache
		slice              1m;
		proxy_set_header   Range $slice_range;
		chunked_transfer_encoding on;
		proxy_ignore_client_abort on;
		proxy_buffering    on;
		proxy_cache        upub_cache;
		proxy_cache_key    $host$uri$is_args$args$slice_range;
		proxy_cache_valid  200 206 301 304 168h;
		proxy_cache_lock   on;
		proxy_pass         http://127.0.0.1/;
	}
}

development

development is still active, so expect more stuff to come! since most fediverse software uses Mastodon's API, μpub plans to implement it as an optional feature, becoming eventually compatible with most existing frontends and mobile applications, but focus right now is on producing something specific to μpub needs

contacts

• new features or releases are announced directly on the fediverse
• direct questions about deployment or development, or general chatter around this project, happens on matrix
• development mainly happens on moonlit.technology, but a github mirror is also available. if you prefer a forge-less development you can browse the repo on my cgit, and send me patches on any contact listed on my site

contributing

μpub can always use more dev time!

if you want to contribute you will need to be somewhat familiar with rust: even the frontend is built with it!

reading a bit of the ActivityPub specification can be useful but not really required

hanging out in the relevant matrix room will probably be useful, as you can ask questions while familiarizing with the codebase

once you feel ready to tackle some development, head over to the issues tab and look around for something that needs to be done!