Intents

[knownasilya]

Intent Scheme: https://github.com/beakerbrowser/beaker/wiki/Intent-Scheme

I've been thinking of working on this and have had some discussions with @pfrazee in IRC, so decided to write down some notes for myself and in case anyone else wanted to come and help out.

Implementing intents as a MVF (Minimum Viable Feature) would include the following:

• Handle the intent protocol and redirect to an internal Beaker page
  • https://github.com/beakerbrowser/beaker/tree/master/app/background-process/protocols
• The Beaker Intent page should take the intent 'type', e.g. 'share' if intent:share and render the registered apps.
  • https://github.com/beakerbrowser/beaker/tree/master/app/builtin-pages
• Clicking an app will send the query params from the intent to that app's registered url

To take this beyond the basics the following might be implemented:

• Ability to add custom apps for intent types (stored in user's profile dat?)
  • currentUserProfile = await beaker.profiles.getCurrentUserProfile()?
• Order apps for intent type by order of usage (also save in profile?)
• Save a default app for intent type (maybe even skip the page if default set, but can be changed from the settings page)
• Expand provided intent apps and types that come by default
• Web API to easily generate intents (maybe?)
  • https://github.com/beakerbrowser/beaker/tree/54ee1f19d8b988ffceab6481f9feaf91f6e46418/app/lib/web-apis

Related Issues

• https://github.com/beakerbrowser/beaker/issues/1060

---

Follow dev here https://github.com/knownasilya/beaker/tree/feat/intents

[knownasilya]

@pfrazee feel free to correct or add anything that needs to be 👍

[pfrazee]

@knownasilya this is looking good. I'd probably just add a new internal web api (so, only exposed to beaker: and intent: locations) called beaker.intents for reading/writing the data.

Thinking forward, there are two other major pieces:

1. The profile database will need a new table for storing the users' saved intents. I haven't totally thought out what schema it will need. At minimum, the profile ID (always 0 for now), the intent name, and the URL of the handler. Not too big of a deal
2. We'll need some way for an application to declare which intents it can handle. This probably needs to be a dat.json field of some kind.

[pfrazee]

@knownasilya for now, if you can just get something serving on intent:share (or similar) with hardcoded handlers, that demos/mocks up the core experience, that'd be a good first step

[knownasilya]

@pfrazee what are you thinking would be on beaker.intents as a start?

For (1) each intent probably needs to also use a certain query param for further filtering. Like in the share example, if your service only shares text, it would have a type: ['text/html'] or something of the sort. Haven't thought through this enough though, and it's definitely not a required feature for a minimal implementation I think.

[pfrazee]

@knownasilya Yeah we can iterate our way to things like that. For now I think all you need is a list/query function that takes the intent name.

[knownasilya]

Still very early and mostly hard coded stuff.

[pfrazee]

Very nice!

[knownasilya]

Works with twitter

[pfrazee]

Nice. I wonder if we'll end up needing a translation between query param names when registering an intent. Eg, "Register for intent:share with the URL of https://foo.com?content={text}". We'll have to see-- obviously it'd be nicer if you could just say "...with the url of https://foo.com" and then have the params be added directly from the intent, with no remapping.

[knownasilya]

Yeah, been wondering the same. We might need a template like that:

let query = '?url=dat://mysite.com&text=hello';
let one = format('?share={text} {url}', query);
let two = format('?url={url}&content={url}', query);

// one => ?share=hello dat://mysite.com
// two => ?url=dat://mysite.com&content=hello

[pfrazee]

There's a fairly detailed spec for URI templates which is overkill for what we need, but might make good inspiration. I'm not sure we'd need more than simple string expansion, but who knows.

[knownasilya]

Yeah, have used that spec format a bit in the past. It might be a good solution so we aren't rolling something that is completely different. But if we can do simple, and then use the spec later without making it a breaking change, that would probably be best.

[pfrazee]

That's true, though that means we inherit that complex spec which I'd only want to do if I thought we needed most of the features

On Thu, Jul 19, 2018 at 2:20 PM Ilya Radchenko notifications@github.com wrote:

Yeah, have used that spec format a bit in the past. It might be a good solution so we aren't rolling something that is completely different. But if we can do simple, and then use the spec later without making it a breaking change, that would probably be best.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/beakerbrowser/beaker/issues/1079#issuecomment-406386073, or mute the thread https://github.com/notifications/unsubscribe-auth/ABNhU1822toApTInLmZlu8oX3T29QQVrks5uINv0gaJpZM4VSE2C .

[RangerMauve]

What about using the same syntax as registerProtocolHandler? It uses %s as a placeholder for the URL.

It seems to be using the syntax for sprintf

[knownasilya]

I think only %s is supported. Would we be able to intercept that navigator call? We'd still have to specify the site as a service provider and then load it and get it's specified configs. Might be a way to do it but also allow manual setup from beaker or from dat.json.

[pfrazee]

Would we be able to intercept that navigator call?

I dont think that's what @RangerMauve was suggesting. Either way, let's not worry about this syntax yet because it's not clear we'll need it.

[pfrazee]

@knownasilya regarding intent registration, I think it'll need to be fields in the dat.json. I have a feeling if sites can prompt the user to install their intent-handlers, it'll become non-stop spam to do so (like with push notifications).

[knownasilya]

I wasn't even thinking about allowing that 😸 Agreed, dat.json is probably best.

[Gozala]

@knownasilya regarding intent registration, I think it'll need to be fields in the dat.json. I have a feeling if sites can prompt the user to install their intent-handlers, it'll become non-stop spam to do so (like with push notifications).

There is also study that supports the claim that permissions at install time causes users to grant permissions without considering what they are. So I would recommend incremental enhancement approach with different spam prevention mechanism:

• Browsers often only allow permission requests form the user event handler, that allows apps to request permission only if user performed certain interaction.
• You don't necessarily need to prompt user on registration, instead you can just add it to a queue and display on intent selection screen on less prime UI estate maybe even folding under "more..." if list provider list grows too big.

[Gozala]

I think advantage of intents over navigator.registerProtocolHandler is that it provides one to many mapping so user can choose on demand. On the other hand navigator.registerProtocolHandler has advantage of more wider browser support.

I wonder if later could be enhanced to support one to many mapping.

[Gozala]

It also might be worth taking a look at Web Activities that Mozilla was pushing as counter proposal to intents & used in Firefox OS.