mastodon.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
The original server operated by the Mastodon gGmbH non-profit

Administered by:

Server stats:

373K
active users

Ben Pate 🤘🏻

Woo Hoo! Check out Baby's first FEP...

If you're a developer, please check out FEP-3b86 at codeberg.org/fediverse/fep/src

I'm working on "Remote Likes" and "Remote Shares" that help you jump back to your own home server to post when you find something cool on another website.

Imagine those "Share on Facebook" buttons, without all the ick.

I know it needs some work (that's what FEPs are for, yea?) so please read, comment, and help me get this over the finish line.

Codeberg.orgfep/fep/3b86/fep-3b86.md at mainfep - Fediverse Enhancement Proposals

I've posted a big update to this proposal on my original PR branch: codeberg.org/benpate/fep/src/b

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!

Codeberg.orgfep/fep/3b86/fep-3b86.md at fep-3b86fep - Fediverse Enhancement Proposals

@benpate when W3C were designing the Web Share Targets API they originally considered using template patterns for the URL, but eventually went for using URL query parameters with get/post form submission so clients wouldn't have to implement a new token-replace function. Would you consider something like that?

@Ben Pate 🤘🏻 Makes me wonder right now: Is integration of OpenWebAuth being worked on in ActivityPub? If so, maybe it's useful for what you're doing because it could facilitate finding your home server.

@jupiter_rowland Yes, I see these two proposals working well together. I tried to keep the scope of this open pretty tight - just focusing on the new WebFinger links. But using this on a client would require some way to “sign in” or at least collect your username/server, which would likely be OpenWebAuth.

@benpate According to RFC 8288 section 3.3, "registered" relation types can not contain a colon:

relation-type  = reg-rel-type / ext-rel-type
reg-rel-type   = LOALPHA *( LOALPHA / DIGIT / "." / "-" )
ext-rel-type   = URI

"Unregistered" relation types should be URIs (though you can argue that intent:Follow is a URN).

IETF DatatrackerRFC 8288: Web LinkingThis specification defines a model for the relationships between resources on the Web ("links") and the type of those relationships ("link relation types"). It also defines the serialisation of such links in HTTP headers with the Link header field.

@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.

@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 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.

www.w3.orgActivityPubThe ActivityPub protocol is a decentralized social networking protocol based upon the [ActivityStreams] 2.0 data format. It provides a client to server API for creating, updating and deleting content, as well as a federated server to server API for delivering notifications and content.

@benpate @silverpill in such a case, you would have the fep define w3id.org/fep/3b86/followUrl or whatever

i haven't yet fully thought out if these should be separate endpoints or if they can be combined into one endpoint by taking a 2nd parameter for the actual intent e.g. (type=follow, type=like, type=announce) versus (/followUrl, /likeUrl, /announceUrl)

@trwnh @silverpill

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?

@benpate @silverpill the POST with authorization is the user interaction. you can also show a web form on GET, if you want?

@trwnh @silverpill

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.

@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

@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.

@trwnh @silverpill

This is an excellent point. It DOESN'T have to be limited to ActivityPub only. These intents *could* work with any other protocol.

itself tries to blend activities across many protocols, with more on the way.

But I *do* like resting atop the Activity Vocabulary because it's already well defined (even if too loosey goosey for my taste).

I've posted some updates to my original PR here: codeberg.org/benpate/fep/src/b

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

@trwnh @silverpill

Codeberg.orgfep/fep/3b86/fep-3b86.md at fep-3b86fep - Fediverse Enhancement Proposals

@silverpill @trwnh

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 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?

@trwnh @silverpill

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 @trwnh A conflict may arise if other developers will start using same IRIs for something different. So I think FEP namespace is preferable, but you can indicate in the proposal that you want to switch to w3.org/ns/activitystreams namespace later.

@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 :)

@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?

@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=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 Yeah, that's basically what I had in mind.

I see what you mean about it being hard to enforce. Maybe it should be required to match the domain in the Referer header?

@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.

@jenniferplusplus Gotcha. I think it's an improvement because I only have to enter my own ID into the site I'm on, which should be easier than navigating back to my home server and copy/pasting a URL.

Combined with some other things, OpenWebAuth or others, I should have a pretty seamless "login" experience across many distributed servers.

@jenniferplusplus

If you've "liked" something before, your Fediverse ID will already be saved in your browser's localStorage. So next time it can take you straight to your site (with some option to erase this data, ofc)

The goal is to avoid copy/pasting URLs, which is an especially awful experience on mobile devices.

If I could avoid having to enter Fediverse IDs too, I would, but that's above my pay grade, and will have to be fixed by some other (browser-based) standard.