When looking up a specfic actor record for a given ActorId, you're pretty much
guaranteed to find the actor if it exists, because there's 1 function in the
codebase that handles this. Whenever a new actor type is added, which is a rare
event, that function gets updated.
But when mass-selecting actors using Esqueleto? Then, you need to LeftOuterJoin
by yourself on each actor type. This is both ugly and error prone, because all
those places in the codebase need to be updated when adding an actor type. The
only downside is that it means O(n) DB queries instead of O(1).
Perhaps there's some elegant way to "add" the specific-actor Joins to a given
Esqueleto query. Something to do some other time, as an optimization, if the
need arises.
Per-actor keys are now fully supported in Vervis! Caveats:
- The HTTP Signature keys produced by Vervis are Ed25519 keys; software that
expects only RSA keys will fail here
- Like instance keys, per-actor keys are currently served in separate
documents, not embedded in the actor document; so software that expects
embedded keys will fail here
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
I'd mention the instance host at least, but YesodMailSend (which I wrote)
provides pure functions for the formatting, so can't access environment
Sometime I'll try to patch yesod-mail-send to have a monadic action there
instead of pure function
It causes first login after verification to redirect to registration page,
which is weird, and the default Yesod falue is False, so, switching back to
False
Because that's what the 'ssh' package knows how to handle
Maybe it can handle OpenSSH format too, anyway I didn't check, may look into
this in the future
Repo/Loom/Deck created one in their migrations, but CollabTopicAccept isn't
itself a topic, it's just a helper, so it needs to *find* the relevant
CollabTopicLocal rather than create a new one.
