> Good lord what is happening in there
Previously the contents of the Web Push API payloads closely resembled the structure of JavaScript's [Notification](https://developer.mozilla.org/en-US/docs/Web/API/Notification). But now that the API is open to non-browser apps, and given that there is no required coupling between contents of the payload and a Notification object, here is how I changed the payload:
```json
{
"access_token": "...",
"preferred_locale": "en",
"notification_id": "12345",
"notification_type": "follow",
"title": "So and so followed you",
"body": "This is my bio",
"icon": "https://example.com/avatar.png"
}
```
The title, body and icon attributes are included as a fallback so you can construct a minimal notification if you cannot perform a network request to the API to get more data.
* Add preference to hide following/followers lists
- Public pages
- ActivityPub collections (does not return pages but does give total)
- REST API (unless it's your own) (does not federate)
Fix#6901
* Add preference
* Add delegation
* Fix issue
* Fix issue
- POST /api/v1/push/subscription
- PUT /api/v1/push/subscription
- DELETE /api/v1/push/subscription
- New OAuth scope: "push" (required for the above methods)
Same URI passed between follow request and follow, since they are
the same thing in ActivityPub. Local URIs are generated during
creation using UUIDs and are passed to serializers.
* Revert "Fixes/do not override timestamps (#7331)"
This reverts commit 9c1e1005f4.
* Document Snowflake ID corner-case a bit more
Snowflake IDs are used for two purposes: making object identifiers harder to
guess and ensuring they are in chronological order. For this reason, they
are based on the `created_at` attribute of the object.
Unfortunately, inserting items with older snowflakes IDs will break the
assumption of consumers of the paging APIs that new items will always have
a greater identifier than the last seen one.
* Add `override_timestamps` virtual attribute to not correlate snowflake ID with created_at
* Add entity cache
Use a caching layer for mentions and custom emojis that are
dynamically extracted from text.
Reduce duplicate text extractions
* Fix code style issue
The goal here isn't to prevent these hashtags from existing, but just to strongly curtail their usage; The hashtags may still exist in the database via federated status, or from being created prior to this feature.
* Update annotate to version 2.7.3
* Update aws-sdk-s3 to version 1.9.2
* Update browser to version 2.5.3
* Update capistrano to version 3.10.2
* Update domain_name to version 0.5.20180417
* Update http to version 3.2.0
* Update lograge to version 0.10.0
* Update oj to version 3.5.1
* Update parallel_tests to version 2.21.3
* Update puma to version 3.11.4
* Update rubocop to version 0.55.0
* Update scss_lint to version 0.57.0
* Update simplecov to version 0.16.1
* Update tty-command to version 0.8.0
* Update tty-prompt to version 0.16.0
* Update pkg-config to version 1.3.0
* Update fog-local to version 0.5.0
* Update fog-openstack to version 0.1.25
* Update devise-two-factor to version 3.0.3
* bundle update
* Force convert to JPG for preview card thumbnails to avoid animations
Fix#7093
* Conditionally convert to JPG only if original is GIF
Coalesce and strip on all formats to ensure no animated APNGs
* Added a timeline for Direct statuses
* Lists all Direct statuses you've sent and received
* Displayed in Getting Started
* Streaming server support for direct TL
* Changes to match other timelines in 2.0
* Add bio fields
- Fix#3211
- Fix#232
- Fix#121
* Display bio fields in web UI
* Fix output of links and missing fields
* Federate bio fields over ActivityPub as PropertyValue
* Improve how the fields are stored, add to Edit profile form
* Add rel=me to links in fields
Fix#121
This also limits the statuses returned by API, but pagination is not
implemented in Web API yet. I still expect it brings user experience
better than making a user wait to fetch all ancestor statuses and flooding
the column with them.
