AkkomaGang/akkoma
AkkomaGang/akkoma
15
65
Fork 92
Code Issues 177 Pull requests 24 Projects 2 Releases 14 Packages Wiki Activity

web+ap protocol handler #589

Closed
smitten wants to merge 12 commits from smitten/akkoma:web-protocol-handler into develop
pull from: smitten/akkoma:web-protocol-handler
merge into: AkkomaGang:develop
Conversation 10 Commits 12 Files changed 6 +367
smitten commented 2023-07-15 04:03:15 +00:00
First-time contributor
Copy link

This is a pass at implementing a web-based protocol handler which could be used to create URLs that reference remote users or posts, but that open locally at your home server.

This idea has been discussed before in a few places but no project has picked it up yet.

see mastodon issue - https://github.com/mastodon/mastodon/issues/19679
see fediverse-ideas issue - https://codeberg.org/fediverse/fediverse-ideas/issues/1

The goal is to register a web-based protocol handler* so that the following use cases would work:

  1. I am reading someone's blog and they want to link me to their fedi profile. Rather than opening the profile on their server then copy-pasting or remote-following, I could open it directly on my server, because it would be in the form of web+ap://portend.place/smitten.
  2. I see a post mentioned on another page, and I want to take actions on it, like star or reply or boost. Rather than copying the address and then searching for it on my home server, I could open it directly with a URL in the form of web+ap://portend.place/notice/AXfa06xMeen4I9wAzI. The page could even link there with an <a> tag.

There are some open questions for how this should behave -

  • What server address should handle the request?
  • What format should the URLs be?

I've gone with Soni's proposals for both of these questions because they seem straightforward and would be easy to implement for other fedi clients.

Server address of /.well-known/protocol-handler?target=%s (see draft for more info)

To prevent running authenticated requests at .well-known, this redirects to /api/v1/akkoma/protocol-handler?target=%s

For the format of the links themselves, I'm using web+ap (see proposal for more info)

Other syntax could be possible in the future, like addressing webfinger handles - e.g. web+ap:acct:smitten@portend.place.

* note that the UI for registering the handler is not part of this PR and would require some frontend work. The relevant JS is available with a static HTML file in web-protocol-register.js.

If there's any interest in Akkoma working to support this feature let me know. happy to tweak this code too, just a WIP.

This is a pass at implementing a web-based protocol handler which could be used to create URLs that reference remote users or posts, but that open locally at your home server. This idea has been discussed before in a few places but no project has picked it up yet. see mastodon issue - https://github.com/mastodon/mastodon/issues/19679 see fediverse-ideas issue - https://codeberg.org/fediverse/fediverse-ideas/issues/1 The goal is to register a [web-based protocol handler](https://developer.mozilla.org/en-US/docs/Web/API/Navigator/registerProtocolHandler/Web-based_protocol_handlers)* so that the following use cases would work: 1. I am reading someone's blog and they want to link me to their fedi profile. Rather than opening the profile on their server then copy-pasting or remote-following, I could open it directly on my server, because it would be in the form of `web+ap://portend.place/smitten`. 2. I see a post mentioned on another page, and I want to take actions on it, like star or reply or boost. Rather than copying the address and then searching for it on my home server, I could open it directly with a URL in the form of `web+ap://portend.place/notice/AXfa06xMeen4I9wAzI`. The page could even link there with an `<a>` tag. There are some open questions for how this should behave - * What server address should handle the request? * What format should the URLs be? I've gone with Soni's proposals for both of these questions because they seem straightforward and would be easy to implement for other fedi clients. Server address of `/.well-known/protocol-handler?target=%s` (see [draft](https://datatracker.ietf.org/doc/draft-soni-protocol-handler-well-known-uri/) for more info) To prevent running authenticated requests at .well-known, this redirects to `/api/v1/akkoma/protocol-handler?target=%s` For the format of the links themselves, I'm using web+ap (see [proposal](https://github.com/fedi-to/fedi-to.github.io/blob/main/webap.md) for more info) Other syntax could be possible in the future, like addressing webfinger handles - e.g. `web+ap:acct:smitten@portend.place`. \* note that the UI for registering the handler is not part of this PR and would require some frontend work. The relevant JS is available with a static HTML file in [web-protocol-register.js](https://akkoma.dev/AkkomaGang/akkoma/pulls/589/files#diff-65756de3ea738feb2ddc210cf8715ae9120ab5c3). If there's any interest in Akkoma working to support this feature let me know. happy to tweak this code too, just a WIP.
smitten reviewed 2023-07-15 04:13:25 +00:00
smitten commented 2023-07-15 13:15:51 +00:00
Author
First-time contributor
Copy link

Tokodon has implemented the web+ap protocol. Tokodon is a client for Plasma.

https://github.com/KDE/tokodon/blob/master/src/network/networkcontroller.cpp#L63-L112

FediText has also added support. FediText is an iOS client.

3373f6ef66

Tokodon has implemented the web+ap protocol. Tokodon is a client for Plasma. https://github.com/KDE/tokodon/blob/master/src/network/networkcontroller.cpp#L63-L112 FediText has also added support. FediText is an iOS client. https://github.com/feditext/feditext/commit/3373f6ef6682617ed49ee2640b8c11eb678b4b18
smitten reviewed 2023-07-16 22:58:01 +00:00
lib/pleroma/web/protocol_handler/protocol_handler_controller.ex Outdated
@ -0,0 +44,4 @@
defp find_and_redirect(%{assigns: %{user: user}} = conn, identifier) do
redirect_to_target(User.get_or_fetch("https://" <> identifier), conn)
|| redirect_to_target(Activity.search(user, "https://" <> identifier, [limit: 1]), conn)
smitten commented 2023-07-16 22:58:01 +00:00
Author
First-time contributor
Copy link

I'm not sure Activity.search is the best method to use here. I couldn't find something like Activity.get_or_fetch() that just took the post URL, but it's probably my unfamiliarity with the code.

The goal would be to find the user or record by their remote URL without doing any fuzzy search querying.

I'm not sure Activity.search is the best method to use here. I couldn't find something like Activity.get_or_fetch() that just took the post URL, but it's probably my unfamiliarity with the code. The goal would be to find the user or record by their remote URL without doing any fuzzy search querying.
darkkirb commented 2023-07-23 08:26:04 +00:00
Contributor
Copy link

There is Pleroma.Object.Fetcher.fetch_object_from_id(id), which should work with any AP object ID

There is `Pleroma.Object.Fetcher.fetch_object_from_id(id)`, which should work with any AP object ID
smitten marked this conversation as resolved
darkkirb commented 2023-07-23 09:36:12 +00:00
Contributor
Copy link

Untested, but I added this code 5bbeeeeedd

Untested, but I added this code https://git.chir.rs/darkkirb/akkoma/commit/5bbeeeeedd84661f65fc9d1e7fc5338f63ed1b0c
smitten commented 2023-07-23 14:28:23 +00:00
Author
First-time contributor
Copy link

Untested, but I added this code 5bbeeeeedd

@darkkirb
Thanks for taking a look. I'm not finding this able to pull a User, I get {:error, "Object containment failed."}

For a post I do get a result back, but I'm not sure immediately how to use it because all the IDs in it are the remote URLs, so I can't redirect to the local representation without another step.

> Untested, but I added this code https://git.chir.rs/darkkirb/akkoma/commit/5bbeeeeedd84661f65fc9d1e7fc5338f63ed1b0c @darkkirb Thanks for taking a look. I'm not finding this able to pull a User, I get `{:error, "Object containment failed."}` For a post I do get a result back, but I'm not sure immediately how to use it because all the IDs in it are the remote URLs, so I can't redirect to the local representation without another step.
darkkirb commented 2023-07-23 19:55:31 +00:00
Contributor
Copy link

Hm, then maybe it should work with only the activity line replaced with my code? I found that particular function by following the code in the search module (Pleroma.Search.DatabaseSearch). Currently working on integrating it with akkoma-fe so I’ll take another look maybe tomorrow

Hm, then maybe it should work with only the activity line replaced with my code? I found that particular function by following the code in the search module (Pleroma.Search.DatabaseSearch). Currently working on integrating it with akkoma-fe so I’ll take another look maybe tomorrow
smitten commented 2023-07-24 15:13:47 +00:00
Author
First-time contributor
Copy link

Hm, then maybe it should work with only the activity line replaced with my code? I found that particular function by following the code in the search module (Pleroma.Search.DatabaseSearch). Currently working on integrating it with akkoma-fe so I’ll take another look maybe tomorrow

Thanks, it needs to pass through Activity.get_create_by_object_ap_id afterwards to get the local 'Create' Activity record. Using DatabaseSearch.maybe_fetch() does both those steps, works well!

> Hm, then maybe it should work with only the activity line replaced with my code? I found that particular function by following the code in the search module (Pleroma.Search.DatabaseSearch). Currently working on integrating it with akkoma-fe so I’ll take another look maybe tomorrow Thanks, it needs to pass through `Activity.get_create_by_object_ap_id` afterwards to get the local 'Create' Activity record. Using `DatabaseSearch.maybe_fetch()` does both those steps, works well!
smitten changed title from WIP: web+ap protocol handler to web+ap protocol handler 2023-07-25 15:41:53 +00:00
smitten added 22 commits 2023-07-25 15:42:02 +00:00
docs: Update Pleroma references to Akkoma in optional packages guide
Some checks are pending
ci/woodpecker/pr/woodpecker Pipeline is pending
Details
b3fc098b83 
This apparently slipped past though all of the doc updates from a while
back.
The frontend got renamed a while back, so the docs should be updated to
reflect that.
Add config for media subdomain for Caddy
Some checks are pending
ci/woodpecker/pr/woodpecker Pipeline is pending
Details
40627a94d4 
A recent group of vulnerabilities have been found in Pleroma (and
inherited by Akkoma) that involve media files either uploaded by local
users or proxied from remote instances (if media proxy is enabled).

It is recommended that media files are served on a separate subdomain
in order to mitigate this class of vulnerabilities.

Based on https://meta.akkoma.dev/t/another-vector-for-the-injection-vulnerability-found/483/2
docs: Add Kaiteki to list of clients
Some checks are pending
ci/woodpecker/pr/woodpecker Pipeline is pending
Details
5fe41df8aa 
Add embeddable posts

Closes #1288

See merge request pleroma/pleroma!2319
fix the /embed endpoint
Some checks are pending
ci/woodpecker/pr/woodpecker Pipeline is pending
Details
593ddbd796
Merge pull request 'Fix the /embed endpoint' (#540) from mikihau/akkoma:develop into develop
Some checks are pending
ci/woodpecker/push/woodpecker Pipeline is pending
Details
210df6fe92 
Reviewed-on: #540
Reviewed-on: #551
Reviewed-on: #555
Reviewed-on: #548
Reviewed-on: #550
Exclude deactivated users from emoji reaction lists
Some checks failed
ci/woodpecker/push/woodpecker Pipeline is pending
Details
ci/woodpecker/pr/woodpecker Pipeline failed
Details
8fe29bf5d2
Correct behaviour of mediaproxy blocklist
All checks were successful
ci/woodpecker/push/woodpecker Pipeline was successful
Details
ci/woodpecker/pr/woodpecker Pipeline was successful
Details
c8904f15a2
Update changelog
Some checks failed
ci/woodpecker/push/woodpecker Pipeline was successful
Details
ci/woodpecker/pr/woodpecker Pipeline failed
Details
f1611b6292
fix ImageMagick typo in media_graphics_packages.md
Some checks are pending
ci/woodpecker/pr/woodpecker Pipeline is pending
Details
43aef8b5b1
Merge branch 'develop' into active-emoji-reactions
Some checks are pending
ci/woodpecker/push/woodpecker Pipeline is pending
Details
ci/woodpecker/pr/woodpecker Pipeline is pending
Details
900b9b0124 
Reviewed-on: #592
Reviewed-on: #593
Allow nil attachments
All checks were successful
ci/woodpecker/push/woodpecker Pipeline was successful
Details
33e7ae7637
darkkirb commented 2023-07-25 15:49:59 +00:00
Contributor
Copy link

My static-fe changes are here: 55bc84da35. I’m unsure about the icon to use, that icon is currently used for “opening on remote instance” on akkoma-fe where I currently use a phone icon. The other suggestion I received was the same icon firefox uses for “open in app”, which is a pro-only fontawesome icon :/

My static-fe changes are here: https://git.chir.rs/darkkirb/akkoma/commit/55bc84da3592c8e63b935ce94ead8c8446a05df3. I’m unsure about the icon to use, that icon is currently used for “opening on remote instance” on akkoma-fe where I currently use a phone icon. The other suggestion I received was the same icon firefox uses for “open in app”, which is a pro-only fontawesome icon :/
smitten commented 2023-07-25 16:20:20 +00:00
Author
First-time contributor
Copy link

My static-fe changes are here: 55bc84da35. I’m unsure about the icon to use, that icon is currently used for “opening on remote instance” on akkoma-fe where I currently use a phone icon. The other suggestion I received was the same icon firefox uses for “open in app”, which is a pro-only fontawesome icon :/

@darkkirb amazing, thanks! I think it does need its own icon, and maybe even a more specific term than 'Open in your client' (although I think that's decently clear).

I made a post to try and get some suggestions around this, I'm really not sure what the best way to represent the idea is.

https://portend.place/notice/AY3f5jqcNfznWGYuIK

> My static-fe changes are here: https://git.chir.rs/darkkirb/akkoma/commit/55bc84da3592c8e63b935ce94ead8c8446a05df3. I’m unsure about the icon to use, that icon is currently used for “opening on remote instance” on akkoma-fe where I currently use a phone icon. The other suggestion I received was the same icon firefox uses for “open in app”, which is a pro-only fontawesome icon :/ @darkkirb amazing, thanks! I think it does need its own icon, and maybe even a more specific term than 'Open in your client' (although I think that's decently clear). I made a post to try and get some suggestions around this, I'm really not sure what the best way to represent the idea is. https://portend.place/notice/AY3f5jqcNfznWGYuIK
smitten commented 2023-07-26 02:10:08 +00:00
Author
First-time contributor
Copy link

I did a poll to try to get feedback and 'Fedi Link' seems to be the most popular. I implemented in akkoma-fe here, using ActivityPub icon:

https://akkoma.dev/AkkomaGang/akkoma-fe/compare/develop...smitten/akkoma-fe:develop

I did [a poll](https://portend.place/notice/AY49HGJL1MLE0qPGcK) to try to get feedback and 'Fedi Link' seems to be the most popular. I implemented in akkoma-fe here, using ActivityPub icon: https://akkoma.dev/AkkomaGang/akkoma-fe/compare/develop...smitten/akkoma-fe:develop
extra-buttons.png
37 KiB
profile-icons.png
43 KiB
extra-buttons.png profile-icons.png
smitten force-pushed web-protocol-handler from c0c8d13404 to 98a117b10b 2023-07-27 20:47:17 +00:00 Compare
smitten force-pushed web-protocol-handler from 98a117b10b to f9feb46d6e 2023-07-27 20:53:55 +00:00 Compare
smitten force-pushed web-protocol-handler from 26df052e8f to 637bca14cc 2023-07-28 19:40:47 +00:00 Compare
smitten force-pushed web-protocol-handler from 05117a0cb3 to 5469a1268e 2023-08-20 17:33:59 +00:00 Compare
smitten commented 2023-08-20 17:41:13 +00:00
Author
First-time contributor
Copy link

I received some good feedback on this from a GoToSocial user who primarily uses Semaphore. They were saying that it's more of a client-side feature exclusively, since we can't know what frontend route is relevant to redirect to.

It's making me think that maybe the redirect behavior is not a good idea, and I should implement this in akkoma-fe instead. (I'm not actually sure how Akkoma handles routes for the various frontend apps, I'm assuming they can choose their own routes independently).

So I may try to rework this so that it's just a new search endpoint, just to cover the specific behavior of looking up the user/post by URI. And then akkoma-fe could hit that endpoint and redirect itself.

I received [some good feedback](https://portend.place/notice/AYKSLKNB7gxo6pg9iK) on this from a GoToSocial user who primarily uses Semaphore. They were saying that it's more of a client-side feature exclusively, since we can't know what frontend route is relevant to redirect to. It's making me think that maybe the redirect behavior is not a good idea, and I should implement this in akkoma-fe instead. (I'm not actually sure how Akkoma handles routes for the various frontend apps, I'm assuming they can choose their own routes independently). So I may try to rework this so that it's just a new search endpoint, just to cover the specific behavior of looking up the user/post by URI. And then akkoma-fe could hit that endpoint and redirect itself.
smitten closed this pull request 2023-10-08 13:26:48 +00:00
smitten commented 2023-10-08 19:25:55 +00:00
Author
First-time contributor
Copy link

Have received a lot of feedback that the backend changes to support this behavior are confusing, I may try a similar PR that is frontend-only. It would be helpful to have a new search endpoint that is more precise (returns only objects matching the queried ID instead of fuzzy search) for the frontend to use, but the web-protocol handler could be defined entirely in the client.

see new proposal on FEP: https://socialhub.activitypub.rocks/t/fep-07d7-a-custom-url-scheme-and-web-based-protocol-handlers-for-linking-to-activitypub-resources/3588

Have received a lot of feedback that the backend changes to support this behavior are confusing, I may try a similar PR that is frontend-only. It would be helpful to have a new search endpoint that is more precise (returns only objects matching the queried ID instead of fuzzy search) for the frontend to use, but the web-protocol handler could be defined entirely in the client. see new proposal on FEP: https://socialhub.activitypub.rocks/t/fep-07d7-a-custom-url-scheme-and-web-based-protocol-handlers-for-linking-to-activitypub-resources/3588
Some checks are pending
ci/woodpecker/pr/build-amd64 Pipeline is pending
Details
ci/woodpecker/pr/build-arm64 Pipeline is pending
Details
ci/woodpecker/pr/docs Pipeline is pending
Details
ci/woodpecker/pr/lint Pipeline is pending
Details
ci/woodpecker/pr/test Pipeline is pending
Details

Pull request closed

Please reopen this pull request to perform a merge.
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels   
approved, awaiting change

   
bug

Something is not working

  
configuration

This requires config changes

  
documentation

This is about human-readable docs

  
duplicate

This issue or pull request already exists

  
enhancement

New feature

  
extremely low priority

   
feature request

Something new?

  
Fix it yourself

Support has been attempted

  
help wanted

Need some help

  
invalid

Something is wrong

  
mastodon_api

   
needs docs

   
needs tests

   
not a bug

   
planned

   
pleroma_api

   
privacy

   
question

More information is needed

  
static_fe

   
triage

   
wontfix

This won't be fixed

No labels
approved, awaiting change
bug
configuration
documentation
duplicate
enhancement
extremely low priority
feature request
Fix it yourself
help wanted
invalid
mastodon_api
needs docs
needs tests
not a bug
planned
pleroma_api
privacy
question
static_fe
triage
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: AkkomaGang/akkoma#589
No description provided.
Delete branch "smitten/akkoma:web-protocol-handler"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?