# μpub
<p align="center">
<img src="https://dev.upub.social/web/assets/icon.png" alt="upub logo: greep mu letter with blue and pink-reddish gradient" height="150" />
</p>
> ## [micro social network, federated](https://join.upub.social)
>
> - [about](#about)
> - [features](#features)
> - [security](#security)
> - [caching](#caching)
> - [deploy](#deploy)
> - [install](#install)
> - [run](#run)
> - [configure](#configure)
> - [development](#development)
> - [contacts](#contacts)
> - [contributing](#contributing)
# about
μpub aims to be a private, lightweight, modular and **secure** [ActivityPub](https://www.w3.org/TR/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](https://ns.alemi.dev/as): **μpub doesn't want to invent another API**!
> [!NOTE]
> a test instance is available at [dev.upub.social](https://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](#media-proxy-cache)
# 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!!)
```sh
$ 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
```sh
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:
```nginx
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](https://dev.upub.social/actors/upub)
* direct questions about deployment or development, or general chatter around this project, [happens on matrix](https://matrix.to/#/#upub:moonlit.technology)
* development mainly happens on [moonlit.technology](https://moonlit.technology/alemi/upub), but a [github mirror](https://github.com/alemidev/upub) is also available. if you prefer a forge-less development you can browse the repo on [my cgit](https://git.alemi.dev/upub.git), and send me patches on any contact listed on [my site](https://alemi.dev/about/contacts)
## contributing
μpub can always use more dev time!
if you want to contribute you will need to be somewhat familiar with [rust](https://www.rust-lang.org/): even the frontend is built with it!
reading a bit of the [ActivityPub](https://www.w3.org/TR/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](https://moonlit.technology/alemi/upub/issues) and look around for something that needs to be done!