search

swicg / general

General issue tracker for the group
https://www.w3.org/community/swicg/
43 stars 2 forks source link

In-Page Social Interactivity #5

Open sandhawke opened 7 years ago

sandhawke commented 7 years ago

Many websites provide no social features, and others have their own extensive custom features. A third class offers social features by outsourcing them to a service provider like Disqus or Facebook Social Plugins.

The advantages of outsourcing social, compared to rolling your own, can potentially include:

But can this be done in a decentralized way? Can sites have this kind of functionality, along the lines of what Disqus and Facebook provide, without signing up with a vendor and requiring their users use the same vendor? Can they offer social features to users who are not willing to use that vendor?

Specific example challenges:

As a very rough example for the first challenge, maybe the website could include markup like '<follow-button>', and the browser could connect it to the user's preferred social networking services provider using a standard protocol. (The big challenge here may be how to polyfill that kind of thing, to get it deployed so the browser vendors start to see the value.)

There is some text in the Social Web WG Charter that could be read as talking about this kind of functionality, and deliverables include "a client-side API that lets developers embed and format third party information such as social status updates inside Web applications", but the given input OpenSocial 2.5.1 Embedded Experiences APIs seems a bit different, and I'm pretty sure the group never worked on anything like this issue.

aaronpk commented 7 years ago

We've experimented with a few different ways of doing this, some of which is documented here: https://indieweb.org/web_action and https://indieweb.org/indie-config I'm not convinced that those are the right approach, but there are some pretty compelling results regardless.

sandhawke commented 7 years ago

Thanks for the links @aaronpk. Can you summarize whether any of the three challenges I mentioned have been achieved? They seems to be framed around only the output side of the problem. But they're long and complicated pages and I might have missed something.

sandhawke commented 7 years ago

Some replies via OStatus in threads starting at https://mastodon.social/@sandhawke/6765114 and https://mastodon.social/@sandhawke/6616663

(Edited to fix links)

nightpool commented 7 years ago

@sandhawke hey, those aren't the permalinks (which look like http://mastodon.social/@[user]/[status] or http://mastodon.social/users/[user]/statuses/[status]). The URLs you gave are to the web ui, which requires a login.

AstraLuma commented 7 years ago

I wonder if some of the other authentication schemes might be useful? Going back to OpenID or maybe Mozilla Persona? I'd have to research their semantics again to know.

I feel like anyone running a single-agent provider is looking to have a centralized online identity and only want to be pseudo-anonymous--I'm not sure we need to take great steps to protect their privacy?

ghost commented 7 years ago

Might have a look at what we did with Hubzilla and "magic-auth" (before I retired from the open hostility of the free web). It basically uses a back channel to validate the existence of a remote session cookie against a remote-id parameter, and if validated provide a cookie on the dest domain. This allows all kinds of interaction across decentralised instances "as if" they all shared a common instance. For instance observer based content, like your example of follow/unfollow toggling. We do a lot of this type of thing in Hubzilla and after 6-7 years of effort we've gotten most cross-domain authenticated interactions to just work and you wonder how the web ever existed without this ability. It allows wall-to-wall posts and comments in a decentralised space (assuming you have permission to do so) and decentralised access control to web resources across domain boundaries. Would be nice to get browser support for something like this, but all I see in that space is corporations fighting for central identification control and I'm quite happy with a solution that's available on all browsers and totally decentralised.

sandhawke commented 7 years ago

Thanks @zotlabs that sounds impressive and useful. Would you mind pointing me (and other readers) at an explanation of the relevant protocols and techniques?

ghost commented 7 years ago

The protocol is called zot and was being developed originally as a federation protocol but there was little interest at the time in solving any problem beyond sending public messages back and forth so we went our own way. Magic auth is simply an identity assertion that is added as a parameter to outgoing URLs (since we don't have browser support). For instance zid=mike@macgirvin.com . The destination site webfingers the identity assertion and if it detects compatibility redirects through the asserted site's auth endpoint to verify the incoming browser session is attached to that identity. Then it does a back-channel crypto dance with the asserted site to verify control of the identity and link it to the current browser visit. If the crypto works a 'visitor' session cookie is assigned and we can use the presence of that to display protected content that is dependent on the observer identity. In addition the current identity is added to outgoing urls from the new site so you can hop around the network and be authenticated the entire time. It allows a lot of the functionality and many of the economies of scale of large centralised social media providers from within a single-user decentralised blog (for instance).

The only thing I need to add is that zot is location independent so the identity assertion is separated into "who you are" (a unique network wide ID) and "where you are" - and these are stored separately. So mike@macgirvin.com and billybob@podunk.edu could in fact both map to the same actor if they both validate.

The crypto dance started off being basically an interpretation of the 'openssh password-less auth' crypto dance but went through a bit of adjustment to provide location independence and webfinger discovery.

This is traditionally where the hostility begins so I'll say up front that I am not pushing this protocol or solutions to anybody. I am treating this as an open exchange of ideas and nothing more.

sandhawke commented 7 years ago

Today, I built a demo of this with protocol handlers. I'm confident it can also be done using nested iframes. I talk about both solutions at https://github.com/tootsuite/mastodon/issues/2291#issuecomment-306013156

akihikodaki commented 7 years ago

I post a comment posted at https://github.com/tootsuite/mastodon/issues/2291#issuecomment-312744708 here, too.

I'm considering to add a handler for application/activity+json and/or one for application/ld+json; profile="https://www.w3.org/ns/activitystreams".

At first I thought it may be difficult because it could not tell whether the type of the activity is Person or not, but the capability to have a different activity type could also be a benefit if we are going to implement a custom handler for them (e.g. implementing a feature to show Note activity with the normal UI for statuses).

Activity Streams itself works as a descriptive profile, and it would also function as a means to connect online. That is neat, IMHO.

However, that will not allow to execute a specific operation such as follow, favourite, boost, etc. It just enables users to see the content in the Web interfaces of their instances.

To solve the issue, I suggest to implement a custom class named Intent. For example, REMOTE FOLLOW button of @alice@instance would be a link for the following activity:

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "type": "Intent",
  "summary": "Following Alice",
  "target": {
     "type": "Follow",
     "object": {
       "id":   "https://instance/@alice",
       "type": "Person",
       "name": "Alice"
     }
  }
}

For details, see https://akihikodaki.github.io/activity-vocabulary-intent/.

Do you think it is good to extend Activity Streams for the purpose? If yes, I will open an issue at ActivityStreams repository to propose this type.

sandhawke commented 7 years ago

Speaking only for myself, I'm not seeing the value to this. I'd need to see how it fit into a complete design for addressing this use case.

tantek commented 7 years ago

@sandhawke do we have a "meta" label for grouping issues like this one?

Could you split each of your specific "Specific example challenges" into their own individual issues to see if perhaps solving them individually is possible? (e.g. one-click follow with current status, one-click like with current status, filtered comments - feel free to pick other labels / summaries)

I think they have different difficulties and security/privacy considerations that may lend them to independent progress.

sandhawke commented 7 years ago

Currently I have my technology hat on, @tantek, so to me it's all one thing, because I see it being solved by one technology. After encouragement on today's call, I think I'll try to do a demo asap, and maybe that'll clarify and narrow what issues remain. At that point, it might make sense as its own repo, built around the draft spec it'll need.

sandhawke commented 7 years ago

I followed up on something @cwebber said, and it turns out @dlongley has used this trusted-iframe-domain approach for making polyfills for Web Payments and Credentials Managements APIs. He pointed me at a nice demo at https://demo.authorization.io/ which shows how the polyfill can offer a UI that feels somewhat like it's part of the browser. Source at https://github.com/Spec-Ops/credentials-polyfill .

I also found the older polyfill for WebIntents, which used the trusted-iframe-domain. (That may actually be where I first learned of this trick.) It's from @PaulKinlan at https://github.com/PaulKinlan/WebIntents/blob/master/src/webintents.js . Worth reading his post mortem of WebIntents at https://paul.kinlan.me/what-happened-to-web-intents/ .

You can view @dlongley as working on 'login' and 'pay' intents, and this swicg issue being about 'like', 'share', 'comment', and 'follow' intents, or something like that.

To get a UX comparable to Facebook's social plugins we'll need a rather different setup that the above designs, though.

tantek commented 7 years ago

@sandhawke I'm a little concerned that "see it being solved by one technology" sounds like a one technology solution looking for a problem (or set of problems), though I doubt that is what you intended. I was hoping to dive into each use-case specifically to narrow the user requirements for each rather than broaden, or depend on any singular technology in particular.

akihikodaki commented 7 years ago

Actually a solution I suggested at https://github.com/swicg/general/issues/5#issuecomment-312752988 is applicable to implement a button to perform an activity, but not for filtered statuses.

ghost commented 7 years ago

I'm still sticking with my solution for my own projects because it covers the whole range of social interactions and provides decentralised privacy of web assets by solving the problem at a higher level. We just deal with automatically authenticated observers and what each is allowed to do (or not do) on your site. This keeps the permissions and privacy on your site where it belongs and represents an integrated approach to the entire problem space. Posts and comments can be submitted "wall-to-wall" just like that big centralised provider and you can control who can do this. The connect button knows if you're connected or not and doesn't need to ask you any questions about who you are, and web pages and photos and videos know if you are allowed to view or edit them.

The iframe approach seems on the surface to require hand-crafting every remote interaction and it isn't clear how one deals with permissions and privacy unless all the private assets are mirrored to a remote site that knows who you are - and this act of mirroring presents its own privacy and permission issues.

So I'm dubious this can ever replace what we're already doing, but Sandro seems pretty clever. It will be interesting to see where this goes. We might be able to leverage something like this for 'social plugins' since we can't really authenticate you if you don't use a service or web node that provides some form of decentralised identity provenance.

sandhawke commented 7 years ago

@zotlabs at the risk of oversimplifying, your approach is that you're always on your own site (or a site you trust), with it's gathering the data from untrusted sites and showing it you to interact with? If so, I agree, that's a nice approach, to the extent you can get people to adopt it. This issue comes up for me in trying to promote adoption.

ghost commented 7 years ago

Actually no - that's more or less the Diaspora solution to the problem. They bring remote profiles to your site for you to interact with. In our model, the remote site authenticates you through an identity assertion which is passed in the url (since browser support for identity is perhaps well into the future). Access control is provided by the site that holds the protected resource. In simple terms my wall knows (and can verify) who is looking at it even if your 'account' and password are on a completely different node. The inner workings are conceptually similar to password-less SSH.

sandhawke commented 7 years ago

So I can't look at your profile without your machine knowing I did that?

ghost commented 7 years ago

The interface is pluggable - you can whitelist or blacklist where you send identity assertions as you choose. Creating a plugin to block your identity from being passed to all sites but your immediate friends or a select group of friends would take ten minutes. Providing an "ask me" and "remember my decision" option would take maybe an hour, with most of that spent making the form look pretty. So far nobody has requested either. One person decided it was so useful they added an option to send identity assertions everywhere - and not just zot-aware sites.

[edit: an addon to restrict authentication to just your friends' sites was just created and published as a demo of how this can all be controlled by you and the ease with which this functionality can be extended. It's called 'authchoose' in https://gitlab.com/macgirvin/red-addons (repository browsing restricted, cloning allowed) and should work with any modern hubzilla release. You can manually authenticate to any site if you change your mind.]

akihikodaki commented 7 years ago

I'd need to see how it fit into a complete design for addressing this use case.

I have implemented a prototype. See https://github.com/tootsuite/mastodon/issues/2291#issuecomment-313302597. I'm for this, a solution with custom protocol scheme and Activity Streams intent because:

Presence of some kind of authority may be acceptable, but I still quest for solutions without authorities if possible. I'm not familiar with zot so I may have missed something, but identity assertion sounds to need navigation from the visitors' own server. We need REMOTE FOLLOW button in Web pages which could be shown by any route. (For example, such pages could be found with a search engine.)

ghost commented 7 years ago

(Thinking out loud...) Actually if you merge that with zot magic-auth you could authenticate with one click coming from anywhere (like Google) and access private resources you've been given access to. That could take our technology up another huge level in capability and Mastodon could also have their remote follow button. We could support that as well for folks who come into our site from Mastodon or wherever who don't have remote identity support and don't care about private media and just want a connect button to send their toots back and forth. Win-win.

akihikodaki commented 7 years ago

That sounds promising, but I have not fully understood the protocol. My primary problem is that the browser does not provide any means to deliver information (namely, the domain of the user's account). How does zot solve the issue?

ghost commented 7 years ago

It is sent as a URL param. As you said earlier this doesn't work well if you visit the link from Google. It works fine "in network" or from your social stream.

The ActivityStreams intent with a scheme or handler looks like a good way to get around the "visiting from Google" problem, and also the cross-project 'follow button' problem. We can currently 'magic-auth' manually (without the magic) by entering our webfinger address in a login box, but reducing either of these interactions to a button click is one more complication of decentralisation reduced to irrelevance.

We investigated iframes early on, but these really need to be handcrafted for every purpose and they look like heck if "your button" isn't aware of the CSS on my site. There also seem to be some advances in cross-domain communication between iframes since I first looked at it a few years ago. Then you had to tunnel small messages between domains through a URL fragment.

Anyway, I can see uses for all kinds of solutions to blur the fact that your "account" and my "account" are on different servers. The more the merrier. I've personally concentrated on decentralised identity because it's a somewhat necessary component in decentralised privacy. Plus my current projects are only peripherally involved in traditional social networking. We're more into cloud storage and content management; where decentralised privacy takes on a more important role.

tantek commented 7 years ago

If we're going to keep discussing this issue as a general class of "In-Page Social Interactivity" with the examples from @sandhawke and others above, I see at least three classes / clusters:

  1. Write-only widgets, e.g. a one-way like button that likes the current post but using your own provider/host/site.
  2. Read-write widgets, e.g. a follow button that both shows you your current following (or not) state of the post's author / profile you're viewing, and lets you follow/unfollow accordingly
  3. Read-only widgets, e.g. a facepile of current RSVPs (from another source) to an event on the page.

I've implemented a working prototype of (3) on the events on my site: tantek.com e.g. http://tantek.com/2017/193/e1/homebrew-website-club

The RSVPs are displayed under the event description, and you'll notice may load slightly after the rest of the page because they're being loaded via an iframe of markup generated by an external service (by @dissolve) from a jf2 data source (webmention.io by @aaronpk ) that is handling receiving webmentions for my site. I can explain more details as needed, however the point of this comment was to provide some analysis and an working example as an illustration of what we're (hopefully) talking about.

akihikodaki commented 7 years ago

An intent feature, which I'm attempting to implement with ActivityPub would be a write-only widget. The problem of the feature in federation has been discussed before and I have proposed a solution.

On the other hand, read-only widgets may also have another difficulty in federation. It is easy to implement create widget button for a post in a page hosted by the server which owns the post. However, federated feeds can also have posts from other servers and it is unknown how to implement create widget button. As a solution, Activity Streams objects may deliver additional information to implement such features. I'm thinking about details of the idea.

akihikodaki commented 6 years ago

Mastodon implemented its own protocol handler in https://github.com/tootsuite/mastodon/pull/4511. Though it proves the idea works well, it depends on Mastodon context and is not on the standard. We should have an issue for Activity Streams (and maybe ActivityPub).

sandhawke commented 6 years ago

I haven't looked at what Mastodon did here -- does it do all the things I mentioned in the intro, like displaying when you visit someone's profile whether you are currently following them?

And yes, it would be nice to have a system that worked beyond Mastodon, but it seems also like that's not necessarily part of AS or AP. It seems to me like a new thing, like "In-Page Social".

akihikodaki commented 6 years ago

does it do all the things I mentioned in the intro, like displaying when you visit someone's profile whether you are currently following them?

No.

And yes, it would be nice to have a system that worked beyond Mastodon, but it seems also like that's not necessarily part of AS or AP. It seems to me like a new thing, like "In-Page Social".

Actually the intent feature is a different representation of activities in Activity Streams and ActivityPub. At least the new spec would refer to those existing specs.

nightpool commented 6 years ago

@akihikodaki I understand that your opinion is that the intent feature should refer to the activities in AS and AP, but currently that's not at all how it's been implemented.

I agree with @sandhawke that this seems like a new thing. It's certainly not part of the AP or AS spec, although it could be built on top of them it seems foolish to limit it to that.

akihikodaki commented 6 years ago

The details of the implementation would not really matter. For example, Mastodon does not use ActivityPub as the client to server interactivity, but its API has definitely the same scope. Here let me describe my idea: The URI social interactivity would be described with three parts: