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

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

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

@benpate so i guess the answer i have rn is:

- build content models that make sense and are at least internally consistent
- build content formats that capture those content models naturally and with minimal effort
- build processing models for publishing and consuming that content format as easily as possible (bearing in mind easy != simple)

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

@trwnh

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 it's close enough, though. you can imagine content models as being like:

- atom:entry
- as:Activity
- html:article

and it is possible for "the same thing" to adhere to more than 1 content model

@benpate This onboarding mechanism looks reasonable, but I think recommended servers should always be specified by the website owner.
Automatic recommendations would do more harm than good.

@dansup @rimu @evan @trwnh @julian @ricferrer

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.

@silverpill @dansup @rimu @evan @trwnh @julian @ricferrer

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