- rationalise activitypub.Reject and fix model being undefined
- fix not being able to follow users from followers page: 'delete' option now in user_options dropdown
- revert bookwyrm.js
- fix delete_follow_request deleting instead of rejecting
- add user id to 'remove-follow' path
The Instance Actor is required for signing http GET requests but is not a "user" and should not be otherwise interacted with.
- hides instance actor profile page, returning a 404
- excludes instance actor from search results and suggestions including in Getting Started
- replaces link to user profile in user admin page with a brief message box
- replaces panel in user admin page that allows for user to be suspended or removed with a message explaining why that is a very bad idea
fixes#3119
* adds the ability to remove a user from your followers list
* fixes verbs.Reject to process reject activities for previously accepted follows in both directions
fixes#2635
activitypub.BookData includes fields for 'files' and 'fileLinks'.
This is a problem because BookData is inherited by Book and Author, neither of which have 'files' as a field in the main model.
Additionally, Author doesn't have a value for 'file_links'.
When serializing to JSON, BookData therefore throws 'TypeError: Object of type _MISSING_TYPE is not JSON serializable'
This fixes the problem by removing links and moving fileLinks to activitypub.Book.
* update User model to allow for moved_to and also_known_as values
* allow users to add aliases (also_known_as) in UI
* allow users to move account to another one (moved_to)
* redirect webfinger to the new account after a move
* present notification to followers inviting to follow at new account
Note: unlike Mastodon we're not running any unfollow/autofollow action here: users can decide for themselves
This makes undoing moves easier.
TODO
There is still a bug with incoming Moves, at least from Mastodon.
This seems to be something to do with Update activities (rather than Move, strictly).
This is essentially a revert of 9cbff312a. The commit was at the advice
of the Celery docs for optimization, but I've since decided that the
downsides in terms of making things harder to debug (it makes Flower
nearly useless, for instance) are bigger than the upsides in performance
gain (which seem extremely small in practice, given how long our tasks
take, and the number of tasks we have).
This is the header described in the ActivityPub spec, which should fix
some federation problems with GoToSocial and potentially other picky
services.
Related: #2794, superseriousbusiness/gotosocial#1676
Previously, ignore_activity could unexpectedly make a outgoing HTTP
connection, leading to unwanted latency, particularly when called via
ActivityObject.to_model, which had the allow_external_connections
parameter already.
Related: #2717
Since we don't use the results of our Celery tasks (all of them return
None implicitly), it's prudent to set the ignore_result flag, for a
potential performance improvement. See the Celery docs for details [1].
We could do this with the global CELERY_IGNORE_RESULT setting, but it
offers more flexibility if we want to use task results in the future to
set it on a per-task basis.
[1]: https://docs.celeryq.dev/en/stable/userguide/tasks.html#ignore-results-you-don-t-want
We should store hashtags case-sensitive, but ensures that an existing
hashtag with different case are found and re-used. for example,
an existing #BookWyrm hashtag will be found and used even if the
status content is using #bookwyrm.
Since the status content already contains rendered HTML when we receive an
ActivityPub inbox message it contains links to the mentioned hashtags on the
originating instance.
To fix this on the receiving instance we need to post-process the status content
after successfully storing the status and its many-to-many fields (the one we're
is the `mention_hashtags`). Post-processing means that we run a regex against the
content to find the anchor tags linking to the originating hashtag and replace the
`href` attribute with the URL to the hashtag page on the receiving (local) instance.
When an inbox activity comes in from another fediverse instance, the
behavior prior to this commit was always to immediately give a 200
response to the external server and then create a celery activity
(usually in the MEDIUM_PRIORITY queue) to complete it.
Instead, this would receive a request and try to complete it without
making any http requests (which would make the request take too long to
process). If an external request is required to complete the activity, a
task is created and added to the queue.
Ideally, this will cause some tasks to happen very promptly, and reduce
the load on celery, which would help queued tasks happen more quickly as
well.
One downside is that this will make completing http requests from
external servers slowing (since it's doing a bunch of thinking before
responding).
- when using raise_for_status we need to catch an HTTPError, not a ConnectionError
- simplify instance actor - use internal email address since it will never be used anyway, and make default username less likely to already be in use.
ERROR HANDLING FIXES
- use raise_for_status() to pass through response code
- handle exceptions where no response object is passed through
INSTANCE ACTOR
- models.User.objects.create_user function cannot take an ID
- allow instance admins to determine username and email for instance actor in settings.py
Authors have Websites. that might be interesting for BookWyrm users. Now there is a field specify the website of an author and it is shown tu users under the wikipedia link
Adds max char for ISFDB ID (6) and ISNI (19 - 16 plus three -)
* New ID: Audible ASIN
Audible belongs to Amazon BUT they do not share the same IDs. The Audible ASIN of an audiobook is never the same as the Amazon ASIN.
Yeah, I know, Amazon is great. The fact that the ASIN is a good distinction for different works and editions bothers me more than I will ever be willing to admint.
* New ID "ISFDB"
Internet Speculative Ficiton Database ID for books and authors.
Links to the entry if set.
* Added aasin to test
Added aasin to test
* the answer expects more emptxy fields...
Properties like "tag" could be lists containing multiple subclasses of
ActivityObject. Make sure to serialize them recursively instead of
outputting them as they are, because otherwise we could get a bunch of
nulls in the resulting JSON and that wouldn't necessarily be a valid
JSON-LD object.
Fix: #2451
These errors in resolve_remote_id aren't really errors, they're
routine problems that we can expect from dealing with the outside world,
like a connection timeout, a server being down, a server being blocked,
et cetera. It's cluttering up the logs and causing unnecessary worry.