| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
sixohsix/pleroma-post_expiration
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
actor"
This reverts commit 2981821db834448bf9b2ba26590314e36201664c.
|
|
NOTE: rewrite the commit msg
|
|
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.
|
|
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.
|
|
|
|
private statuses)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
AccountView: Add user background.
See merge request pleroma/pleroma!1280
|
|
we can't change module attributes and endpoint settings in runtime
|
|
|
|
|
|
Explicit addressing
See merge request pleroma/pleroma!1239
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Generic settings store for frontend user settings
See merge request pleroma/pleroma!1221
|
|
|
|
|
