* Verify link ownership with rel="me"
* Add explanation about verification to UI
* Perform link verifications
* Add click-to-copy widget for verification HTML
* Redesign edit profile page
* Redesign forms
* Improve responsive design of settings pages
* Restore landing page sign-up form
* Fix typo
* Support <link> tags, add spec
* Fix links not being verified on first discovery and passive updates
When serializing an ActivityPub actor, Mastodon checks for the existence
of the avatar/header files. This is not necessary, only check if avatar/header
is set.
fd8bf49d38/README.md (checking-a-file-exists)
Conflicts:
.circleci/config.yml
app/controllers/authorize_follows_controller.rb
app/javascript/packs/public.js
Moved new stuff from packs/public.js to core/public.js.
Added appropriate use_pack in new controllers.
* Add remote interaction dialog for toots
* Change AuthorizeFollow into AuthorizeInteraction, support statuses
* Update brakeman.ignore
* Adjust how interaction buttons are display on public pages
* Fix tests
Conflicts:
app/models/status.rb
db/migrate/20180528141303_fix_accounts_unique_index.rb
db/schema.rb
Resolved by taking upstream changes (no real conflicts, just glitch-soc
specific code too close to actual changes).
Conflicts:
app/controllers/accounts_controller.rb
app/javascript/mastodon/locales/pl.json
app/views/about/more.html.haml
Conflicts in `accounts_controller.rb` resolved by taking upstream's
version + our `use_pack`.
Conflicts in `pl.json` resolved by taking upstream's changes.
Conflicts in `aboute/more.html.haml` resolved by taking upstream's changes.
Conflicts:
Dockerfile
app/javascript/packs/common.js
config/webpack/loaders/sass.js
config/webpack/shared.js
db/schema.rb
package.json
yarn.lock
A lot of the conflicts come from updating webpack.
Even though upstream deleted app/javascript/packs/common.js, I kept
glitch-soc's version as it unifies JS/CSS packs behavior across flavours.
Ported glitch changes to webpack 4.x
Conflicts:
README.md
app/controllers/statuses_controller.rb
app/lib/feed_manager.rb
config/navigation.rb
spec/lib/feed_manager_spec.rb
Conflicts were resolved by taking both versions for each change.
This means the two filter systems (glitch-soc's keyword mutes and tootsuite's
custom filters) are in place, which will be changed in a follow-up commit.
* Add keyword filtering
GET|POST /api/v1/filters
GET|PUT|DELETE /api/v1/filters/:id
- Irreversible filters can drop toots from home or notifications
- Other filters can hide toots through the client app
- Filters use a phrase valid in particular contexts, expiration
* Make sure expired filters don't get applied client-side
* Add missing API methods
* Remove "regex filter" from column settings
* Add tests
* Add test for FeedManager
* Add CustomFilter test
* Add UI for managing filters
* Add streaming API event to allow syncing filters
* Fix tests
Conflicts:
app/javascript/mastodon/initial_state.js
db/schema.rb
Upstream added a new field to initial_state.
Not too sure about what happened with db/schema.rb though…
* Track trending tags
- Half-life of 1 day
- Historical usage in daily buckets (last 7 days stored)
- GET /api/v1/trends
Fix#271
* Add trends to web UI
* Don't render compose form on search route, adjust search results header
* Disqualify tag from trends if it's in disallowed hashtags setting
* Count distinct accounts using tag, ignore silenced accounts
> 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.
- 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.
