Discussion
Re: I've been thinking a lot about #ActivityIntents and how to make it easy for people to find and join the #SocialWeb
@benpate@mastodon.social depends... who's hosting the web intent button code and handling all of the behind the scenes tasks?
What are the buy-in requirements for each implementor, 3b86?
I see value in it, but I am not entirely sure if the flow is expected. I haven't clicked a "share to facebook" (or similar) button in years, if ever, but I am not the target user.
Hey #FediDev gang.. Do you think this is the right way to guide people from personal/organizational websites into the #Fediverse?
Some of this is defined in #FEP3b86. Some of it exists today in #Emissary (and the #oStatus "remote follow") some is being built by @dansup as #WebIntents, and some is just scribbles on paper.
If there's interest, I'm happy to write up the rest of this as an additional #FEP
Yes. Great point. At best, automatic recommendations would need some heavy moderation.
Also, each segment of this process should be its own swappable API, so sites can mix and match the solution that fits them.
The initiating website should choose what it recommends - including just using a static list of one or more servers to point to. That config could live in the HTML widget(s) we build.
Re: I've been thinking a lot about #ActivityIntents and how to make it easy for people to find and join the #SocialWeb
@benpate@mastodon.social depends... who's hosting the web intent button code and handling all of the behind the scenes tasks?
What are the buy-in requirements for each implementor, 3b86?
I see value in it, but I am not entirely sure if the flow is expected. I haven't clicked a "share to facebook" (or similar) button in years, if ever, but I am not the target user.
@julian Sorry, I didn't answer one of your questions
3b86 is very helpful, esp. for less common activities such as "Like" - so it would be great to get that metadata into WebFinger at a minimum.
But for simple "Follow" activities, we can also guess common endpoints by sniffing your server type. It's messy, but it'll work until we have better adoption.
That's what I'm doing server-side in #Emissary, and I believe @dansup is planning something similar for #WebIntents.
@julian Great points. It could be done in swappable stages, with each step being an open API.
The widget itself could probably be done in pure, self-hosted javascript.
Location lookups are more ambitions, and would need server support. We could probably make self-hosted / shared server for this. Just a few providers would be enough.
FediDB (or some compatible API) provides the list of available servers, possibly vetted by the work being done by @MastodonEngineering for their signup button.
@benpate personally my goal is to guide people from fediverse into personal websites, not the other way around ^_^;
@trwnh Another admirable goal, to be sure! Traffic in both directions is a win.
Are there specific things we can build that will facilitate this?
@benpate that is what i'm trying to figure out for at least myself before writing up any recommendations for others. the hardest part for me so far is actually how to organize everything, what to name things, etc -- approaches and conventions moreso than tooling or technologies. i want it to be as easy or even easier to post to my website than to post to social media. a lot of that involves figuring out workable content models!
I'll be interested to see where this goes. I looked into implementing the Micropub API (https://indieweb.org/Micropub) at one point. There's lots of client apps that already use it, which is a plus.
This is probably different from what you're describing, but it might be an interesting comparison.
@benpate micropub is okay; its content model is mf2-based and it acts like a cms for h-entry h-card h-event and h-cite. that could be useful for powering something that maps pretty close to 1:1 onto atom entries (and h-entry is intended to be that 1:1 mapping onto atom:entry actually!) but i haven't gotten around yet to finding that useful because i do less "blog"-like work and more "wiki"-like work.
@benpate using activities as an example of a content model: the outbox is a collection you can POST to and publish activities. this is ~doable as a self-contained microservice, but is there an even easier or more minimal way that requires even less overhead and maintenance? what is the sum total of all requirements needed to make it actually work?
@benpate if all of this more or less lives inside a sort of "container" with its own "filesystem" then it becomes far more portable, which is what i'm trying to make fall out of my work naturally. you can take your outbox "around" to whatever service provider is willing to host it. with inboxes, it can be the same thing with taking your inboxes "around" to whatever provider is willing to host them. similar to how IMAP lets you both download *and* upload messages.
