Explain the role of WM agent

[sidvishnoi]

Had a chat with @adrianhopebailie about this.

Assumption is that the agent is either something the user installs from a 3rd party or is built in to the browser and configurable by the user. It makes the decision WHEN to pay and HOW MUCH and it could do this based on a variety of inputs such as the URL of the site, the user’s preferences, a block-list, a allow-list etc. If the agent decides to pay, it should use a Payment Handler to make the payment (if we go the PH way). It kind of makes sense that the WM Agent and the PH come from the same entity, but it’s not a requirement.

We need to discuss the role of WM agent and what inputs it can get from the browser, while being consistent with one of the major goals of the project:

it must not be possible for the user's Web Monetization provider to get details of a user's browsing history

[sidvishnoi]

Also, this may be out of scope of the normative aspects of the specification:

Should the agents be built into the browser, or available as extensions? If we consider agents to be browser extensions, we can probably follow a stricter review process, to ensure no sensitive user data is sent outside the browser. The extensions may have special privileges and restrictions to qualify as WM agent, i.e., the browser communicates inputs directly with extension, and the extension should not have read access to the current page (or maybe a more a restrictive permission model, whatever is easier for browsers).

I think a browser extension would be better than adding the agent within the browser as it's easier to maintain, offers independent updates and encourages more agents in the marketplace.

[justmoon]

I agree that the low hanging fruit definitely seems to be to assume that WM providers are extensions. We don't know what inputs WM Agents will use to determine how much to pay a given site. But right now, WM extensions have to request unrestricted access to every page and it would be awesome if there was a more limited permission (read WM metadata state and emit monetizationprogress events) that they could ask for instead. They might still request other permissions (such as being able to read the URL of the page) but those could be more granular and therefore better for privacy and security. It would also allow different WM providers to differentiate themselves by asking for fewer permissions.

Over time, standard practices might emerge - i.e. most providers might settle on similar permissions that they ask for and if/when that happens we could think about a standard that provides a more lightweight process for setting up a WM Agent than installing an extension. But I don't think we can know what that interface should look like yet.

[sublimator]

Should the agents be built into the browser

If you are talking about landing code drops in browsers (such as Chrome/FF) with WM Agent functionality, then extensions definitely come out looking golden in contrast. That seems almost like a non-starter.

We had toyed with the idea of breaking up the current extension (that has complete access) into 1 WM polyfill extension that communicated with an Agent extension with a light manifest. This would also allow one clear owner of document.monetization. At the moment Coil is the only WM Agent/impl in town so it's not an issue. iirc the thinking was that if you have multiple WM extensions installed, you could just use the browser extensions settings to enable only one at a time.

For various reasons, including not wanting to require people to have install 2 extensions, we never went ahead with multi extension architecture.

[sublimator]

One thing off the top of my head that the Coil extension does with its "all access pass":

• Gets a login token from coil.com using content scripts
  • Though that wouldn't necessitate the current permission we are currently using as we could simply request permission for coil.com.

We also "adapt" content from twitch/youtube urls, monetizing pages that don't have a meta (or link) tag embedded.

[sublimator]

Then of course there are the UI elements:

• tipping
• disabling

[sidvishnoi]

It would also allow different WM providers to differentiate themselves by asking for fewer permissions.

I like this idea!

[WM agents] emit monetizationprogress events

I'm not sure, but doesn't this force extensions to require unrestricted access to read/modify page's content? I think there should be a way for WM agents to communicate monetization state/progress directly with the browser, and the browser in turn should inform the page (instead of browser listening to events on page and using that to modify its state like amount paid per site, UI etc.).

[networkimprov]

Assumption is that the agent is either something the user installs from a 3rd party or is built in to the browser and configurable by the user

Isn't the point of a W3C spec that the browser implements it completely?

Asking users to install third-party extensions would hinder growth of WM, expose users to security risks, and require WM providers like Coil to maintain (or test against) extensions for numerous browsers.

Related: #195 - Spec missing WM provider HTTP API

[AlexLakatos]

The Web Monetization Agent is what the browsers would implement. It's responsible to:

• get the rate, token, and BTP address from the Web Monetization Provider
• get the payment information from the link
• create a STREAM connection
• package an ILP package
• send the package to the BTP address from the provider

The Web Monetization Provider would be side-loaded via an extension, essentially giving users the ability to choose their provider by installing a different extension. It would only be responsible to offer the browser information about the rate, token and BTP address. Ideally, there would be a separate extension category for Web Monetization Providers.

[sublimator]

I see @AlexLakatos's model (recent comment from December 3rd ish) is a bit different to @sidvishnoi's , though they both rely upon extensions, rather than some web protocol (some browser UI for configuring providers that talk some protocol)

Sid's model might be an easier sell in terms of impl burden for browsers. I wonder also if there is more flexibility if the provider has complete control of the STREAMs and where they are initiated from (maybe not even in the browser). Providers may want to differentiate themselves via different payment scheduling, rather than a steady rate.

It may also be preferable to be able to update more of the functionality more frequently which would be afforded by extension update mechanisms better than browser updates.

Another consideration is that STREAM doesn't have a hard dependency on BTP (that I know of), yet in this model it would.

package an ILP package send the package to the BTP address from the provider

@AlexLakatos Can you clarify what you mean by package there?

[AlexLakatos]

Sorry, non-native English speaker here, messed up package and packet. I meant an ILP Packet, as defined by the Interledger Protocol Specification.

[AlexLakatos]

We've documented this in the Glossary now: https://webmonetization.org/docs/resources/glossary/#web-monetization-agent