I've been thinking a lot about #ActivityIntents and how to make it easy for people to find and join the #SocialWeb
-
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
@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.
-
R relay@relay.mycrowd.ca shared this topicR relay@relay.an.exchange shared this topic
-
@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!
-
@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 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 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.
-
@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.
-
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 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:articleand it is possible for "the same thing" to adhere to more than 1 content model
-
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.
