1
0
Fork 0
mirror of https://code.sup39.dev/repos/Wqawg synced 2024-12-28 11:54:51 +09:00
vervis/migrations/498_2022-10-03_forwarder.model
fr33domlover 32c87e3839 Improve the AP async HTTP delivery API and per-actor key support
New iteration of the ActivityPub delivery implementation and interface.
Advantages over previous interface:

* When sending a ByteString body, the sender is explicitly passed as a
  parameter instead of JSON-parsing it out of the ByteString
* Clear 3 operations provided: Send, Resend and Forward
* Support for per-actor keys
* Actor-type-specific functions (e.g. deliverRemoteDB_D) removed
* Only the most high-level API is exposed to Activity handler code, making
  handler code more concise and clear

Also added in this patch:

* Foundation for per-actor key support
* 1 key per actor allowed in DB
* Disabled C2S and S2S handlers now un-exported for clarity
* Audience and capability parsing automatically done for all C2S handlers
* Audience and activity composition automatically done for Vervis.Client
  builder functions

Caveats:

* Actor documents still don't link to their per-actor keys; that should be the
  last piece to complete per-actor key support
* No moderation and anti-spam tools yet
* Delivery API doesn't yet have good integration of persistence layer, e.g.
  activity is separately encoded into bytestring for DB and for HTTP; this will
  be improved in the next iteration
* Periodic delivery now done in 3 separate steps, running sequentially; it
  simplifies the code, but may be changed for efficiency/robustness in the next
  iterations
* Periodic delivery collects per-actor keys in a
  1-DB-transaction-for-each-delivery fashion, rather than grabbing them in the
  big Esqueleto query (or keeping the signed output in the DB; this isn't done
  currently to allow for smooth actor key renewal)
* No support yet in the API for delivery where the actor key has already been
  fetched, rather than doing a DB transaction to grab it; such support would be
  just an optimization, so it's low-priority, but will be added in later
  iterations
2022-10-12 16:50:11 +00:00

121 lines
2.2 KiB
Text

RemoteActor
RemoteActivity
Role
OutboxItem
Workflow
Forwarding
recipient RemoteActorId
activity RemoteActivityId
activityRaw ByteString
signature ByteString
forwarder ActorId
running Bool
UniqueForwarding recipient activity
ForwarderPerson
task ForwardingId
sender PersonId
UniqueForwarderPerson task
ForwarderGroup
task ForwardingId
sender GroupId
UniqueForwarderGroup task
ForwarderRepo
task ForwardingId
sender RepoId
UniqueForwarderRepo task
ForwarderLoom
task ForwardingId
sender LoomId
UniqueForwarderLoom task
ForwarderDeck
task ForwardingId
sender DeckId
UniqueForwarderDeck task
Person
username Username
login Text
passphraseHash ByteString
email EmailAddress
verified Bool
verifiedKey Text
verifiedKeyCreated UTCTime
resetPassKey Text
resetPassKeyCreated UTCTime
actor ActorId
-- reviewFollow Bool
UniquePersonUsername username
UniquePersonLogin login
UniquePersonEmail email
UniquePersonActor actor
Group
actor ActorId
UniqueGroupActor actor
Repo
vcs VersionControlSystem
project DeckId Maybe
mainBranch Text
collabUser RoleId Maybe
collabAnon RoleId Maybe
actor ActorId
create OutboxItemId
loom LoomId Maybe
UniqueRepoActor actor
UniqueRepoCreate create
Deck
actor ActorId
workflow WorkflowId
nextTicket Int
wiki RepoId Maybe
collabUser RoleId Maybe
collabAnon RoleId Maybe
create OutboxItemId
UniqueDeckActor actor
UniqueDeckCreate create
Loom
nextTicket Int
actor ActorId
repo RepoId
create OutboxItemId
UniqueLoomActor actor
UniqueLoomRepo repo
UniqueLoomCreate create
Actor
name Text
desc Text
createdAt UTCTime
inbox InboxId
outbox OutboxId
followers FollowerSetId
UniqueActorInbox inbox
UniqueActorOutbox outbox
UniqueActorFollowers followers
Outbox
Inbox
FollowerSet