In the "pleroma" section of the MastoAPI for status activities you can
see an expires_at item that states when the activity will expire, or
nothing if the activity will not expire.
The expires_at date is only visible to the person who posted the
activity. This is the conservative approach in case some attacker
decides to write a logger for expiring posts. However, in the future of
OCAP, signed requests, and all that stuff, this attack might not be that
likely. Some other pleroma dev should remove the restriction in the code
at that time, if they're satisfied with the security implications of
doing so.
If we didn't put some kind of lifetime requirement on these, I guess you
could annoy people by sending large numbers of ephemeral posts that
provoke notifications but then disappear before anyone can read them.
The "expires_at" parameter accepts an ISO8601-formatted date which
defines when the activity will expire.
At this point the API will not give you any feedback about if your post
will expire or not.
Add a table to store activity expirations. An activity can have zero or
one expirations. The expiration has a scheduled_at field which stores
the time at which the activity should expire and be deleted.
While debugging the follow breakage, I observed that our sharedInbox usage
did not match the rules in the specification. Accordingly, I have better
aligned our usage of sharedInbox with the rules outlined in the ActivityPub
specification.
the redundant checks assumed a POST request, which will not work for signed GETs.
this check was originally needed because the HTTPSignatures adapter assumed that
the requests were also POST requests. but now, the adapter has been corrected.
Almost all AP servers return their key ID as the actor URI with #main-key
added. Hubzilla, which doesn't, uses a URL which refers to the actor
anyway, so worst case, Hubzilla users get refetched.
Fixes `Plug.Conn.NotSentError` that causes a 5xx error in response
instead of 404 and 400.
Fixes pattern matching error caused by different response format
in test and non-test env: `Pleroma.Emails.Mailer.deliver_async` returns
:ok when PleromaJobQueue is enabled and `{:ok, _}` when it's disabled.
In tests, it's disabled.
