57 lines
4.3 KiB
Markdown
57 lines
4.3 KiB
Markdown
|
# f3l
|
||
|
|
|
||
|
|
activity tracker. 100% compliant with the activitypub "federated server" conformance profile.
|
||
|
|
|
||
|
|
## what does it do
|
||
|
|
|
||
|
|
per the "federated server" conformance profile of the activitypub specification, you can:
|
||
|
|
|
||
|
|
- POST an as2 Activity to outbox for delivery processing
|
||
|
|
- POST an as2 Activity to inbox to receive deliveries
|
||
|
|
|
||
|
|
## what does it NOT do
|
||
|
|
|
||
|
|
anything not required by the activitypub specification is out of scope. this includes but is not limited to:
|
||
|
|
|
||
|
|
- behaviors and side effects that are recommended in activitypub but not required.
|
||
|
|
- behaviors and side effects not described in activitypub. this is an implementation of the activitypub protocol. it aims to be compliant with the activitypub specification and nothing more.
|
||
|
|
- anything the "fediverse" does.
|
||
|
|
- authentication and authorization. if you want that, use a reverse proxy.
|
||
|
|
|
||
|
|
## why
|
||
|
|
|
||
|
|
to prove a point.
|
||
|
|
|
||
|
|
many activitypub partisans talk about how easy it is to implement activitypub, and how doing so enables compatibility with numerous projects, many of which are part of what is called the "fediverse". to anyone who looks further into these claims, it should quickly become apparent that activitypub is a necessary but not sufficient component of the communication protocol of the fediverse. furthermore, the "protocol of the fediverse" is implicit, not explicit; there is no formal definition for the complete set of behavioral requirements that are prerequisite to communicating with any given fediverse project which nominally speaks "activitypub". in the absence of such a formal definition, softwares that participate in the "fediverse" often implement "activitypub" as defined by some primary target for their interoperability. for example, a project targeting interoperability with mastodon will likely follow <https://docs.joinmastodon.org/spec/activitypub> in implementing what is informally known as the "mastodon flavour", "mastodon profile", or "mastodon protocol".
|
||
|
|
|
||
|
|
this project therefore exists as a counterbalance to the above issue. rather than targeting "activitypub" as defined by the "mastodon protocol", it targets "activitypub" as defined by the "activitypub specification".
|
||
|
|
|
||
|
|
## is this useful
|
||
|
|
|
||
|
|
maybe. probably not to most people, especially if you want to talk to people on the "fediverse". but i intend to use this to power a page on my website that tracks my activities. this is the most minimal viable usage of activitypub that i can think of. the page will be available at https://trwnh.com/now or something, and it will draw its data from https://trwnh.com/activities or some other thing which will be reverse proxied.
|
||
|
|
|
||
|
|
## the requirements
|
||
|
|
|
||
|
|
almost everything is optional, including delivery (per https://github.com/swicg/meetings/tree/main/2023-11-17#ap-issue-297 errata). one could argue that it is possible to fully comply with activitypub by implementing outbox and inbox endpoints that accept an HTTP POST and then do absolutely nothing with it, but
|
||
|
|
|
||
|
|
### section 7.1.1: outbox
|
||
|
|
|
||
|
|
- target inboxes for delivery based on values of to/cc/audience/bto/bcc (errata https://github.com/swicg/meetings/tree/main/2023-11-17#ap-issue-297 changes this to a SHOULD but not incorporated yet)
|
||
|
|
|
||
|
|
### section 7: s2s delivery
|
||
|
|
|
||
|
|
- don't add new recipients other than what's in the addressing properties (to/cc/audience/bto/bcc)
|
||
|
|
- dereference any collections "with the user's credentials"; limit collection depth when discovering inboxes
|
||
|
|
- dedupe the final recipients list
|
||
|
|
- exclude yourself from the recipients list (per https://github.com/w3c/activitypub/issues/480 maybe this should be relaxed)
|
||
|
|
- POST to any ldp:inbox discovered with `Content-Type: application/ld+json; profile="https://www.w3.org/ns/activitystreams"` (arguably this type should have never been defined, but it is what it is) (also per errata https://github.com/swicg/meetings/tree/main/2023-11-17#ap-issue-297 this is changed to a SHOULD but not incorporated yet)
|
||
|
|
- Create/Update/Delete/Follow/Add/Remove/Like/Block/Undo (and Announce?) require an `object`
|
||
|
|
- Add/Remove require a `target`
|
||
|
|
|
||
|
|
### 7.1.2: inbox forwarding
|
||
|
|
|
||
|
|
- forward any activity being seen for the first time if the to/cc/audience contains a collection owned by you and the activity is relevant to some local object (by way of inReplyTo, object, target, tag)
|
||
|
|
|
||
|
|
### 7.5: Follow activity
|
||
|
|
|
||
|
|
- if you get a Follow in the inbox and respond with a Reject Follow, do not add that actor to your followers
|