zaaarf/upub
1
0
Fork 0
forked from alemi/upub
Code Pull requests Activity
micro social network, federated
466 commits 2 branches 2 tags 3.3 MiB
Rust 98.2%
HTML 1.8%
Find a file
alemi 597dee934d
fix: try hiding locked activities for public objs 
idk if this works but basically when there's a public object from a
private activity, the query joins the activity anyway because it uses
the object relation, try using the addressing relation and see what
comes out
2024-04-23 17:21:32 +02:00
apb feat(apb): added all outbox routes, authed inbox 2024-04-22 22:42:45 +02:00
src fix: try hiding locked activities for public objs 2024-04-23 17:21:32 +02:00
web fix(web): dont use two object_id fields 2024-04-23 03:59:12 +02:00
.editorconfig chore: initial commit with environment 2023-12-30 05:07:49 +01:00
.gitignore chore: gitignored trunk dist 2024-04-14 17:23:48 +02:00
.rustfmt.toml chore: initial commit with environment 2023-12-30 05:07:49 +01:00
.tci ci: fix trunk compile jobs (must use env var) 2024-04-14 17:35:41 +02:00
Cargo.toml feat: fetch threads recursively up to 16 2024-04-22 00:43:17 +02:00
README.md docs: updated progress 2024-04-22 20:10:27 +02:00

README.md

μpub

micro social network, federated

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

μpub is currently being developed and can do most basic things, like posting notes, liking things, following others, deliveries and browsing

all interactions must happen with ActivityPub's client-server methods (basically POST your activities to your outbox), and there's a simple frontend

a test instance is usually available at feditest.alemi.dev

upub's stock frontend is also being developed and can be viewed usually at feditest.alemi.dev/web

about 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

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)

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

contributing

all help is extremely welcome! if my cgit looks too scary there's a github mirror you can open issues or PRs on. get in touch with me (fedi is fine, but a mail works too), i'd be thrilled to showcase the project to you!

progress

  • barebone actors
  • barebone activities and objects
  • activitystreams/activitypub compliance (well mostly)
  • process barebones feeds
  • process barebones inbox
  • process barebones outbox
  • http signatures
  • privacy, targets, scopes
  • simple web client
  • announce (boosts)
  • threads
  • editing
  • searching
  • media
  • user fields
  • mastodon api
  • hashtags, discovery
  • polls
  • lists
  • more optimized database schema

what about the name?

μpub, sometimes stylyzed upub, is pronounced mu-pub (the μ stands for micro)

frontend

upub aims to be compatible with multiple frontends via the mastodon api, but a simple custom ui is also being worked on

screenshot of upub simple frontend