Woo Hoo! Check out Baby's first FEP...If you're a #Fedidev developer, please check out FEP-3b86 at https://codeberg.org/fediverse/fep/src/branch/main/fep/3b86/fep-3b86.mdI'm working on "Remote Likes" and "Remote Shares" that help you jump back to your ...
-
@benpate Where does the user's browser get sent after the action is complete? Are they left having to manually navigate back to the site they just left, or should there be a way to provide a redirect URL to their home server?
-
@silverpill Yeah, I knew I was probably going to get bit by web standards. And I *DO* want to follow the best standards.
What do you think would be the best approach here? I think it's important to keep it short, and as semantic/descriptive as possible.
-
@FenTiger *This* FEP is only about exposing the data so that people CAN do remote likes. Right now, I think that particular part of the workflow is important, but is currently left to the server once the action is complete.
Do you think we should step our toes into the whole workflow process, and add a recommendation like "... After this process is complete, servers SHOULD" redirect back to the originating client." ?
-
@benpate Well, my gut feeling is that the server hosting the Like (or whatever) button should be in control of what happens after it's been clicked, which means a redirect back to a page which it specifies.
I haven't thought this through at all - it's just an initial idea - and in particular there will have to be some kind of protection against open redirects here.
-
@FenTiger Yes. I follow you.
So, we could add a URL parameter.. something like βredirect=https://client.orgβ that the server βSHOULDβ obey, and redirect to once this interaction is complete.
Possibly with a same-origin policy? Though Iβm not sure how weβd enforce that in code.
That sounds like a great idea.
-
@benpate There is a
fep
namespace at https://w3id.org, perhaps you can use it:rel: https://w3id.org/fep/3b86/FollowIntent
-
@silverpill @benpate my thinking was why not reuse the activitystreams iris? rel=https://www.w3.org/ns/activitystreams#Follow for example?
one other thing: what about using query params or form data params similar to how proxyUrl endpoint works? resource=https://mastodon.social/users/trwnh&activity=Follow or something similar
-
@benpate oh hell yeah congratulations!
-
@trwnh @silverpill Yes. W3.org domains are absolutely the right answer. I think Iβll make updates to the FEP later this afternoon..
Iβm still trying to dig into what you mean by passing parameters similar to the proxyUrl endpoint. Let me do my homework and get back to you?
-
@benpate @silverpill https://www.w3.org/TR/activitypub/#proxyUrl
so you'd have an endpoint which takes a parameter `id` and then basically invokes the intent against that object. for proxyUrl it just fetches the object:
```
POST /proxyUrl HTTP/1.1
Authorization: ...id=https://...
```you could define similar endpoints, expose them in `endpoints` and not just webfinger, etc.
-
@benpate tbh, I don't understand what problem this is solving. It sounds like it's meant to solve the problem where you open a link to some content on a remote server, and you have to copy that url into the search bar on your home server to do anything with it.
But you would still have to do essentially that thing. Am I missing something?
-
@jenniferplusplus I should probably write up the rest of the workflow so it's more clear.
It's just like oStatus "remote follows" but for other interactions such as: create, like, announce.
So, you visit my band website, and see a cool album you want to share with your friends. There's a little "share" button you can click on.
The "share" button opens a pop-up that asks you to enter your Fediverse ID. When you do, you're redirected to your home server to confirm the "share"
-
@benpate Right, yes. What I'm saying is that I don't see how this is an improvement on the present situation.
-
Activity Intents still need to have some user interaction. So I'm not sure how proxyUrl would apply.
Take the case of the Mastodon `/share` link. I get the text or URL pre-populated (nice!) but I still want to add my own comments.
"Like" intents should still be confirmed to my home server.
And "Follow" intents may require additional workflow from the UI.
The Intent gets me to the doorstep, but I still have to walk through the door on my own. Yes?
-
Sorry, I meant to answer this directly, but I'm still catching up.
In the original FEP, I tried to address the FEP namespace from w3id.org. There's a lot of good reasons to use it. But I'd hate to have to type `/fep/3b86` over and over. It's not very semantic, so I went looking for something else.
What do you think of using `w3.org/ns/activitystreams/#Follow`? Are those IRIs off limits for some reason? If not, it seems like a pretty good fit.
-
@benpate @silverpill the POST with authorization is the user interaction. you can also show a web form on GET, if you want?
-
@benpate @silverpill i donβt think it makes sense to be concerned about typing things. and if that was the case, then the fep iri is shorter and easier to type. but it doesnβt matter because these are intended to be machine-readable primarily, right?
-
Yes. And sorry for being dense. I think I'm missing something.
I'm assuming that it would be enough for a "client" website to just link back to someone's home server. That the input form would be generated by the home server. So I don't understand where the proxy would come into play.
Can you help me understand the workflow as you're seeing it? Because it sounds a lot more sophisticated (which is a good thing) than what I was originally aiming at.
-
Yeah... typing is just an analogy. Machine readability is obviously a requirement, but I'd like to make them as "human readable" as possible.
I was on my phone before, so the URLs were getting garbled. I think like your suggestion best of all - using URLs like: `w3c.org/ns/activitystreams#Follow`
That seems pretty human-and-machine-readable, and is owned by the W3C. Would that work?