Add support for remote interaction ([this thing](https://eldritch.cafe/users/Barmaid/remote_follow) in mastodon)
- [x] create the endpoint dispatching remote interactions to local pages
- [x] add this endpoint to web-finger
- [x] propose remote interaction when following and not connected
- [x] propose remote interaction when liking/sharing and not connected
- [x] propose remote interaction when commenting and not connected
- [x] fetch posts/comments we don't know but remote interaction was requested for ?
* Big refactoring of the Inbox
We now have a type that routes an activity through the registered handlers
until one of them matches.
Each Actor/Activity/Object combination is represented by an implementation of AsObject
These combinations are then registered on the Inbox type, which will try to deserialize
the incoming activity in the requested types.
Advantages:
- nicer syntax: the final API is clearer and more idiomatic
- more generic: only two traits (`AsActor` and `AsObject`) instead of one for each kind of activity
- it is easier to see which activities we handle and which one we don't
* Small fixes
- Avoid panics
- Don't search for AP ID infinitely
- Code style issues
* Fix tests
* Introduce a new trait: FromId
It should be implemented for any AP object.
It allows to look for an object in database using its AP ID, or to dereference it if it was not present in database
Also moves the inbox code to plume-models to test it (and write a basic test for each activity type we handle)
* Use if let instead of match
* Don't require PlumeRocket::intl for tests
* Return early and remove a forgotten dbg!
* Add more tests to try to understand where the issues come from
* Also add a test for comment federation
* Don't check creation_date is the same for blogs
* Make user and blog federation more tolerant to errors/missing fields
* Make clippy happy
* Use the correct Accept header when dereferencing
* Fix follow approval with Mastodon
* Add spaces to characters that should not be in usernames
And validate blog names too
* Smarter dereferencing: only do it once for each actor/object
* Forgot some files
* Cargo fmt
* Delete plume_test
* Delete plume_tests
* Update get_id docs + Remove useless : Sized
* Appease cargo fmt
* Remove dbg! + Use as_ref instead of clone when possible + Use and_then instead of map when possible
* Remove .po~
* send unfollow to local instance
* read cover from update activity
* Make sure "cc" and "to" are never empty
and fix a typo in a constant name
* Cargo fmt
Upgrade rust-toolchain
Upgrade Tantivy
Warning: tantivy now use a different file format, search index may need to be deleted and recreated to work as intended
try to run compile twice in a row because sometime oomk is evil
* Update some UI strings for more natural English
* Correct message text
* Correct message text
* Update the strings everywhere
Because they are also used as base messages for other languages
* Implement find_for_comment for notifications
* Delete notifications when deleting a comment
This should tackle #463
* Apply rustfmt
* Implement `find_for_mention` and remove order by from `find_for_comment`
There is no need to order the notifications
* Delete notifications for mentions
* Fix notifications for comments and mentions
Also adds a parameter to `md_to_html` to only render inline elements (so that we don't have titles or images in blog descriptions). And moves the delete button for the blog on the edition page.
I still have to update the SQLite migration once others PRs with migrations will be merged.
Also, there will be a problem when you edit a blog while not owning its banner or icon: when validating they will be reset to their default values… I don't see a good solution to this until we have a better way to handle uploads with Rocket (the same is probably happening for articles btw).
And the icon/banner are not federated yet, I don't know if I should add it to this PR or if it can come after?
Fixes#453Fixes#454
We add clippy as our build — also rectifying the missing `plume-cli` build!
In the next step we follow clippy's advise and fix some of the "simple" mistakes in our code, such as style or map usage.
Finally, we refactor some hard bits that need extraction of new types, or refactoring of function call-types, especially those that thread thru macros, and, of course functions with ~15 parameters should probably be rethought.
* Slightly improve the media experience
- Use a grid to display the list of media
- Add icons for non-image media preview
- Paginate the gallery
- Add links to the gallery in the editor and in the profile settings to make it more discoverable when you need it
Fixes#432
* Allow video and audio tags in SafeString
Otherwise we can't display their preview, nor show them in articles
Also show controls by default for these two elements
* Show fallback images for audio and unknown files, to make them more visible
* Add a new constructor to SafeString when the input is trusted and doesn't need to be escaped.
And use it to generate media previews.
* Make it possible to insert video/audio in articles
* Password reset
* Various improvements and fixes for password reset
- Reorganize src/mail.rs to make it cleaner
- add a build_mail function
- only make the requests invalid after 2 hours
- avoid infintely-growing list of requests by deleting them once completed, or after 24 hours
- avoid sending many requests for the same user
- validate the password reset form
* Avoid locking so many times
Fix durations
* Remove old requests even if the current one is not valid
* Remove unused feature
* Also remove the custom_derive and plugin features while we are at it
* Forgot a 0 è_é
* Avoid panicking while owning a request lock
* Use master branch of lettre so that we can build with the latest OpenSSL
* Fix the debug mailer
Fix#433
I added the repo link to Cargo.toml so that `software.repository` could be configurable like @rhaamo suggested. I don't know if it's ok to include `software.repository` without bumping the schema version, but I didn't know if that would break any clients that parse nodeinfo with a hardcoded schema version.
* Allow customizing max form size from env vars
* Add error page for unprocessable entities
And change default http port to 7878
* Improve char counter: under the editor, more discrete, and give it a default value
This pull request add a `categories` key to the web manifest. The categories key was [recently added](https://www.aaron-gustafson.com/notebook/categories-land-in-the-web-app-manifest/ "Blog post detailing the addition of categories to the spec") to the Web Manifest spec and is a list of categorizations you want to apply to your site that serves as a hint to search engines and webapp catalogs.
The categories can be anything and there is no standardized list of vaues. The W3C is maintaining a list of commonly used values [here](https://github.com/w3c/manifest/wiki/Categories). I added _social_ to Plume's manifest based on that list, but I think eventually allowing a user defined list would be better. I don't know if there's anything in Plume currently that would enable that.
- Use `Result` as much as possible
- Display errors instead of panicking
TODO (maybe in another PR? this one is already quite big):
- Find a way to merge Ructe/ErrorPage types, so that we can have routes returning `Result<X, ErrorPage>` instead of panicking when we have an `Error`
- Display more details about the error, to make it easier to debug
(sorry, this isn't going to be fun to review, the diff is huge, but it is always the same changes)
Add some support for comment visibility, fix#217
This add a new column to comment, denoting if they are public or not, and a new table linking private comments to those allowed to read them. There is currently no way to write a private comment from Plume.
Git is having a hard time what happened in Comment::from_activity, but most of it is just re-indentation because a new block was needed to please the borrow checker. I've marked with comments where things actually changed.
At this point only mentioned users can see private comments, even when posted as "follower only" or equivalent.
What should we do when someone isn't allowed to see a comment? Hide the whole thread, or just the comment? If hiding just the comment, should we mark there is a comment one can't see, but answers they can, or put other comments like if they answered to the same comment the hidden one do?
* Fix some follow issues
Fix not receiving notifications when followed by remote users
Fix imposibility to be unfollowed by Mastodon/Pleroma users (tested only against Pleroma)
* Fix notification on every post
* Fix issues with federation
Send Link instead of Object when emiting Follow request
Receive both Link and Object for Follow request
Don't panic when fetching user with no followers or posts from Pleroma
Reorder follower routes so Activity Pub one is reachable
* Generate absolute urls for mentions and tags
* Verify author when undoing activity by Link
* Remove use of String for body parameters
Create SignedJson and implement FromData for it
* Make Travis test on release
* Remove warning when installing and fix coverage
* Count items in database as much as possible
* Fix the tests
* Remove two useless queries
* Run pragma directive before each sqlite connection
* Pragma for tests too
* Remove debug messages
