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 ...
-
@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?
-
-
@benpate @silverpill i guess i would ask: what do *you* see as the workflow here? At least for an AP C2S client, they can just construct a Follow/Like/Announce/Create and POST it to outbox... a mastodon client can load the object via search and so on...
the "missing bit" is something like mailto:?subject=&body= that can be handled by some client app. right? so why does this have to be handled by the home server at all? in fact, why does this have to be limited to fedi? can it be a generic share
-
@benpate @silverpill my suggestion of extending proxyUrl assumed you want to fetch an object and then present it in the client with optional actions
-
@benpate @silverpill put another way: intents are to be used by the *client*, not the server, and i suspect there is a bit of ambiguity here because most of fedi is currently built on monolithic instances that include both a server *and* a client.
-
@benpate @silverpill you might want to look at Web Intents as prior art
-
@silverpill @trwnh This is an excellent point. We should go ahead like this.
Once this get out in the wild, changing these identifiers is nearly impossible, so let's just go with `w3id.org/fep/3b86/*` and not plan on any changes.
It looks like this will forward directly to the FEP on codeberg, so there's nothing else I need to do to "reserve" this URL.
Awesome. I'll make some changes and send an update
-
I've posted a big update to this proposal on my original PR branch: https://codeberg.org/benpate/fep/src/branch/fep-3b86/fep/3b86/fep-3b86.md
It addresses (most?) (all?) of the issues you all have raised.
I really appreciate your attention to this. It's already made the FEP so much better. So, thank you!
-
@trwnh @silverpill Thank you, yes.. I did dig into the original browser "Web Intents" specs.
I think this name got co-opted by Twitter (the good, old one) which was more of what I based this FEP on.
I think a lot of confusion arose from the "client" and "server" names that I used, because I didn't mean "client" as in "web browser", but "client" as in "the other server" calling WebFinger.
I've updated the FEP with a ton of other stuff, including this correction that (I hope) reads better.
-
I've posted some updates to my original PR here: https://codeberg.org/benpate/fep/src/branch/fep-3b86/fep/3b86/fep-3b86.md
I'm pretty pleased with these changes. I think it alleviates some of the confusion, and it locks down the specific parameters that each intent would accept.. which, addresses one of my specific pain points with ActivityStreams in general.
Let me know if this new revision makes sense to you? I *really* appreciate the attention you've given this so far; it's already far better because of your feedback