The Interledger Community 🌱: Sid Vishnoi

Memorable wallet addresses on your own domain

Sid Vishnoi — Tue, 02 Sep 2025 11:34:33 +0000

Wallet addresses are meant to be easy to remember or identify, unless your wallet provider chooses them for you. The address might include a long subdomain or even a random series of numbers and characters. But did you know that if you own a domain, you can set your wallet address to be the same as your domain?

So, instead of https://ilp.wallet.example/12345432/usd, you can have $mywebsite.com as your wallet address (well, technically, a payment pointer)! It’s as easy as pie to remember.

I personally use $sidvishnoi.com (which maps to my GateHub wallet). Feel free to send me money now that you remember the address!

Alright, so how do we get that address?

Continue reading on the Interledger Tech Blog

CityJS Singapore 2024 - Web Monetization extension demo booth

Sid Vishnoi — Fri, 06 Sep 2024 12:26:35 +0000

On July 26th 2024, we (@ioana, @devcer and @sid) attended CityJS Singapore. This post summarizes our activities and booth presence for Web Monetization. I’ll recap our attendance from the technical perspective (not marketing), specifically the live demo of the extension.

One important note is that the audience there was primarily JS developers. From my understanding, most of them (if not all) weren't aware of the existence of Web Monetization prior.

The Demo

We demonstrated the extension over the Web Monetization playground (as of that date) using wallet addresses from the Rafiki test net. The live demo of the extension ran smoothly for the most part.

However, towards the second half of the day, https://rafiki.money started running into performance issues, causing the payments to not go through within the extension's request timeout period (10s). These issues hindered the ability to demonstrate the extension further, but over the entire duration, there was at least one visible MonetizationEvent on the page as a demo.

Note: This post was originally written on Aug 13. The performance of rafiki.money has improved a lot since then, so we don't expect our next such demo to have a slow down.

Despite this setback, attendees were keenly interested in our booth (I suspect our t-shirts attracted them a lot).

We also mentioned that we're working on a native browser implementation, which will make the extension redundant in the future.

Audience Perception of the Extension + WM

The attendees perceived the Web Monetization interface as simple and intuitive, noting that the implementation (adding a link tag to HTML) was straightforward.

People also asked how they knew if the payments went through, which is when we demonstrated the JS API.

Notably, people were more curious about the backend - Open Payments, rather than the extension or WM. The extension got very little attention.

The audience expressed disappointment over limited support for wallets in their regions/currencies, given only Fynbos and Gatehub exist. We encouraged them to play using the test wallet to help promote WM until we've more wallets.

Concerns

Several attendees had concerns about legal compliance and potential abuse of the system. Explaining that wallet addresses are synonymous with banks, which follow their due diligence when connecting with other wallets, eased their doubts. But then they were asking if this is an alternative to tech like SWIFT transfers (it’s an abstraction over all those things).

Additionally, a pair of individuals inquired about the security of the extension, particularly the origin and safety of the private/public keys.

Key Takeaways

Despite the primary focus on open payments, the concept of Web Monetization resonated with developers. Several expressed enthusiasm for the potential of WM to support content creators, particularly those operating blogs or art websites.

The core technology (open payments) is a more prominent interest area than the extension/WM itself!
The extension's UI is considered user-friendly enough, but there are not enough data points to claim it as is.
Expanded wallet support is crucial for adoption.
Addressing legal and security concerns is essential for building trust.
Developer interest in Web Monetization is promising.

Recommendations

For future demonstrations about Web Monetization and the extension, we need a way to explain the extension and WM-specific features and benefits while avoiding people getting distracted by the Open Payments side.
Clarify communication to address legal and security concerns:
- Show how their money is safe (the security keys).
- Clarify they can avoid supporting something they don't wish to support (via the continuous payments toggle)
- Show users that the website won’t know “who is paying” (privacy)
Engage with the non-developer community to foster adoption, as it's mostly "simple and clear" from the dev side.
Instead of a live demo as the main screen, use prettier slides, videos, and promotional banners. We used a QR code for the challenge and more-info links, which was very useful.

Bringing Web Monetization to the Web Platform — Grant Report #2

Sid Vishnoi — Wed, 24 Feb 2021 12:46:29 +0000

Project Update

I'm thrilled to share that we now have a Firefox version with native Web Monetization support!

The goal for this final milestone was to bring the actual Web Monetization support to Firefox. In my previous post, I discussed two approaches to support web monetization in browsers and explained why I'm prototyping with the browser extension approach.

Progress on objectives

The primary objectives under this milestone were:

Figure out a way to support WebMonetization in browsers,
Implement it in the browser, and
Provide feedback to the stakeholders.

As explained in my previous post, I decided to prototype WebMonetization in Firefox by defining a new browser extension API. I proposed a minimal API and asked the folks in Interledger Slack channel for their feedback. The API design was based on the Coil Web Monetization extension. We refined the API following some discussions on various requirements - like manually refreshing SPSP response on expiration and pause-resume events.

I also explored whether exposing only the "monetizationprogress" event is enough as the WebAPI and if we can achieve similar results by removing the monetization.state attribute and start/stop events. So, the present WebAPI is as simple as:

monetization.addEventListener("progress", event => {
  console.assert(event instanceof MonetizationProgressEvent);

  const { amount, assetScale, assetCode } = event;
  const url = event.url; // paymentPointer as a URL

  if (event.receipt) {
    const isValidReceipt = verifyReceipt(event.receipt);
  }
});

Key activities

Figure out Extension vs PaymentHandler

When I first proposed this project, the aim was to study (and support) if any new protocols need to be implemented in browsers to support Web Monetization. It turned out that no new protocols were needed, as ILP can work over HTTP and WebSocket protocol.

Later, when I started the project, the Payment Handler API appeared to be the proposed way to support various payment providers. Another approach was to make use of browser extensions, though it comes across as less than ideal.

My decision became simpler as Firefox doesn't support Payment Handler API and implementing it would be beyond the scope of this project. It means the "WebMonetization Agent" now has two responsibilities: making payment decisions, as well as paying.

Define a minimal extension API

I proposed multiple variants of the browser extension API in the Interledger/WebMonetization Slack channel and asked for their feedback. The API essentially lets extensions know when to start/stop/pause/resume payments, where to send the money (i.e., the SPSP response), and provides a way to notify the website when a payment is successful. Extensions can build upon this basic API, while still being able to request additional information through other extension permissions.

As of now, we've settled on this API (alternatively, see TypeScript definition) and hope it will be taken up by the WM community.

Understand how to develop an extension API in Firefox

Developing an extension API in Firefox was uncharted territory for me. Thankfully the documentation for extension APIs is much better maintained than the rest of the code I've worked with. After going through the docs, referencing the implementation of different extension APIs, and exploring a lot of indirectly related code, I figured out how to implement the WM BrowserExt API.

Setup communication between extension, browser and websites

Once I had mock implementations in place, the next thing was to stitch them all together. The communication model involves passing messages across three different kinds of processes. Firefox already had the infrastructure in place, so the implementation was pretty straight-forward (apart from avoiding race conditions due to the event-driven behavior).

Implement the WebAPI

Until now, the browser "communicated" monetization progress to the webpage by logging messages to the JS-console, so the next step was to emit real MonetizationProgress events that websites can monitor.

Based on some conversations in the Interledger community, I decided to expose only "progress" events to the global monetization API. It appears that we can achieve similar results with only progress events, and the monetization.state attribute and start/stop/pending events might be redundant. Though, websites might need a way to know if the user can make payments.

There is also a discussion in WM repo to move document.monetization to a global namespace (Window), or attach it to the Navigator interface. I initially added it to the Navigator, but later moved it to Window, as Navigator is typically used with hardware related APIs. In other words, document.monetization is now window.monetization.

Write Usage Examples

I developed a WebMonetization Firefox extension using the above prototyped APIs. The extension is a proof-of-concept and doesn’t include many features that a real world extension might. It is mainly a payment handler without any user interface.

As a companion to the extension, I also created several playgrounds to test various aspects of the WebMonetization implementation in Firefox. The tests include the behavior of dynamic monetization tags, content security policy, caching, in addition to a few modified examples from the WebMonetization website like payment counters and receipts.

You can follow the instructions to run the tests and the extension here.

Share feedback with WM community and Mozilla

I've shared my implementation notes and recommendations with Mozilla, which you can also access in the wiki. I'm sharing my feedback with the WM community through this report.

Remaining activities

Even though my grant period concludes with this report and all required tasks accomplished, I'll still participate in the WebMonetization community and hopefully provide useful feedback.

What community support would benefit your project?

As I discussed in my previous post, a roadblock in the adoption of WebMonetization through browser extensions is the installation process itself. It's not a long process, but it certainly has more friction than merely viewing an ad. I am curious to know what you feel about the friction of installing an extension for WebMonetization and the aspects of having a default built-in extension.

I would also love your feedback on how the Extension and Web APIs work for you. Please feel free to ask questions and suggest improvements!

Additional comments

I'll be writing some technical blog posts on how I prototyped Web Monetization in Firefox. Follow me on Twitter if you're interested!

Relevant links/resources

Implementation of Web Monetization in Mozilla Firefox:
- Code
- Downloads
Extension with Native APIs
Playground

Browser Extension vs Payment Handler API

Sid Vishnoi — Thu, 14 Jan 2021 11:45:09 +0000

There are two fundamental requirements to satisfy while implementing Web Monetization natively in browsers:

ability to make cross-site authenticated payments in the background, and
provide some context to the WM Agent to guide a payment decision (whether to pay, how much to pay etc.).

Both requirements must be fulfilled while preserving the user's privacy.

At a technical level, two strategies become apparent: Browser Extension and Payment Handler API. In this article, I'll weigh the pros and cons of each.

Browser Extension

Extensions have been around in web browsers almost since forever. So, their existence is arguably known to most users.

Extensions run the most privileged user-land code and have access to powerful APIs not available to regular web pages, which can come in handy with Web Monetization:

Authentication: An extension can access cookies at the payment provider's website to authenticate.
Browser Sync: An extension can synchronize payment decision models and stats on various devices for a user without sending the user's data to a third-party.
Browsing history and payment decision: Having some access to a user's browsing history and behavior can help understand whether they would be happy to pay a website more or less, ensuring money goes where the user prefers. Partial access to history (i.e., metrics like how often the user visits the current website) can help with payment decisions without disclosing what website the user is viewing - a big win for privacy.

It's also a bit easier to support browser-specific extension APIs than adding features to the Web Platform.

The biggest roadblock in the adoption of Web Monetization as a browser extension is requiring users to install the extension in the first place. This is difficult as browser extensions appear to be more of a power user thing. The most popular Firefox add-on has 4.5M users compared to total 210M Firefox users. That's 2% of total users. The next most popular extensions have 2M and 1M users each. Chrome has around 0.3% extension users (10M of 3B). These numbers aren't very encouraging.

It's also essential to educate the users of the cost and benefits of the extension. Does the extension have too broad permissions? Is there enough incentive to learn about and install a browser extension, compared to viewing an ad that required nothing to install? Privacy-aware users agree, but what about the rest?

Also, Chrome, the most used browser, doesn't support extensions on mobile at all. Though not all hope is lost as Firefox on Android supports extensions very well. Samsung Internet and iOS Safari also have partial support.

A natural approach to removing the friction above could be adding a default built-in Web Monetization extension in the browser. It could be similar to how browsers let users choose search engines.

Payment Handler API

Payment Handler API is a proposed API that enables WebApps to handle payment requests. Technically, it lets a service worker (a kind of background worker script) of a website handle payment at another site. Presently, the API is experimental and only supported in Chrome and Edge.

As a first impression, a website can conveniently request the user to install a payment handler - in a way, it's as simple as visiting a website. The browser extension certainly requires more clicks. Also, using Payment Handler and Payment Request APIs means reusing the Web Platform, and preventing an entirely new standard.

It's relatively less work for a payment provider to create and publish a payment handler when compared to a browser extension. There will be the same API across all browsers, unlike extensions (though extensions should also be standardized). Publishing is as straightforward as hosting a JavaScript file on their own website.

Authentication in a payment handler is smoother as the service worker runs on its website as a first-party, hence can authenticate requests on the same origin easily. It's also safer as a payment handler by some website X cannot authorize requests for some other website Y (unlike allowing an extension made by website X to access cookies on another site Y).

Though, as a payment handler doesn't have access to a user's browsing history, it becomes difficult to model payment decisions. A workaround could be to provide additional context in the PaymentRequest call. Nevertheless, determining what context is needed by a handler, and how more or less information can be requested is difficult, and could quickly lead to privacy concerns. With extensions, browsers can provide some primitive context, and extensions can ask for more permissions if needed. Also, once added, removing things from the web platform becomes difficult.

Also, the lack of a browser-sync capability in a payment handler means user details will need to be sent to the payment provider's website if they're to be shared across devices.

My initial thoughts for using the Payment Handler API were to treat the browser as an intermediary and not expose the payment handler method to the website. That is, the browser invokes the PaymentRequest instead of the website. This allows the browser to supervise payments (and not the website) and provide the additional context needed for the payment decision.

The way forward

Initially, I wanted to prototype the native Web Monetization implementation using the Payment Handler API because that meant reusing the Web Platform. Unfortunately, Firefox does not support the Payment Handler API, nor they intend to implement it any time soon. So, I went with the next best approach: a browser extension API. (It would be great if someone gets to experiment with the Payment Handler approach also!)

You might wonder we can already use Web Monetization with Coil's browser extension, so what benefit does adding an extension API add?

The most significant benefit is privacy. Presently, any extension will require complete read-write access to every website you visit. Read access is required to find the payment pointer on the current website. A malicious extension can read more than just the payment pointer. Write access is required to notify the website of the monetization progress. A malicious extension can write a lot more than monetization progress. With an extension API, the browser acts as an intermediary between the extension and a website. It provides the extension with details like whether to pay and where to pay in a privacy-preserving manner. It also provides secure communication of monetization progress to the website.

Secondly, as the browser is acting as an intermediary, it can consistently inform the user of payment status and record, and allow the user more control over which sites get paid and how much.

Additionally, fundamental logic can be handled by the browser, demanding less effort from extension authors.

Summary

I have already created a working implementation of the Web Monetization with the extension API in my fork on Firefox. Shortly, I'll share with you a Firefox release that you can test and provide feedback on. I'll also try to work with Coil folks so we can have a working extension that uses the native APIs.

Edit (Jan 18, 2021): Came across a Firefox Data Dashboard, that shows the most popular add-on has 3.9% users (my 2% calculation was incorrect). Even better, around 35% Firefox users worldwide have at least one add-on installed. Now that's more encouraging!

Exploring integration of Web Monetization into the Web Platform — Grant Report #1

Sid Vishnoi — Wed, 02 Dec 2020 11:20:43 +0000

Project Update

The primary objectives for this milestone were to decide whether to use the <meta> or <link> tag and then implement the same in Gecko (Firefox's browser engine). I'm happy to inform you that both of these goals have been successfully accomplished!

Spoiler alert: using <link> is my recommended way forward for the Web Monetization community. More details below.

Progress on objectives

The objectives under the current milestone were:

Study relevant specifications and Gecko infrastructure.
Discuss and decide whether to use the <meta> or <link> element.
Integrate the said element's behavior in Gecko.

`<link>` is the way forward

Following a discussion outlining various pros and cons of each tag, and a deep dive into various specifications and Gecko infrastructure, we decided to go with the <link> tag. This means the browser should support:

<link rel="monetization" href="URL" />`

Instead of:

<meta name="monetization" content="$paymentPointer" />

This is a breaking change to the specification, and, because of the impact of the change, a difficult decision for the WM community to adopt. We would essentially be abandoning "payment pointers" — which are well-known in the Web Monetization community — with something that better aligns with the web platform: using regular URLs. I won't get into the technical details here, but you can read the summary of my research in the GitHub issue.

Bringing it to the browser

Once the WM community reached consensus to to go with the <link>, I proceeded to implement this declarative API in a fork of Firefox at GitHub. Note that the present implementation only handles the fetching and processing of the monetization endpoint (payment pointer), and not the actual monetization.

You can download the current implementation from GitHub. At the time of writing, it supports:

Getting monetization details from the first valid <link> element at any time. That is, if you add or remove or modify the link elements, the monetization info is updated. This way, dynamic monetization tags support revenue sharing and single-page applications (SPA) use cases.
Monetizing only the currently visible tab in the browser (no background tabs).
Fetching the payment info with proper HTTP headers, while respecting CORS policy and cache-control behavior, as defined by the SPSP protocol.
To preserve user's privacy, no referrer information (i.e., the URL of current website) or cookies are sent to the monetization receiver (e.g. Uphold).
Allowing only legitimate payment pointers through the use of a Content Security Policy (CSP). By using the monetization-src <source>; CSP directive, we can enforce monetizing only certain payment pointers so that malicious actors cannot steal your money.
Logging error messages and other information to the browser console.

A more up-to-date implementation status can be read in the project's wiki.

The implementation presently does not support monetization of embedded content like iframes. That needs more discussion from the security and performance perspective, and also requires specification of various edge cases. Nevertheless, those cases have been captured in a GitHub issue.

Key activities

Note: This section contains some technical details and my journey.

Initial research

I started with going through with various specifications, specifically HTML, DOM, Fetch, InterLedger Protocol, Payment Pointers, Web Monetization, W3C Tag Design Principles, RFC8288 (Web Linking) and RFC2718 (Guidelines for new URL Schemes), to get a better understanding of the platform as a whole.

After familiarizing myself with the specs, I went through Firefox code-base and documentation to analyze how the existing Gecko infrastructure can be used to support <meta> or <link> monetization tags.

After studying for a few weeks and various discussions with Marcos Cáceres, I started to summarize my notes into a write-up that can be used by the Web Monetization community to settle the debate whether we should move forward with <meta> or <link> tag.

As of today, we've settled on using the <link> tag.

Set up development environment

Now as we can't just implement a specification that is not presently on standards track into a browser, I created my own fork of Firefox on GitHub. This allowed me to prototype quickly, without the hassle of integrating a particular feature flag for Web Monetization (generally, something that can be time consuming to add).

Aside: One thing I found interesting is that GitHub doesn't let you push a large repository (4GB in this case) in one go. I had to write a script to split the repository into smaller batches of commits and push them instead (that took a while).

I'll write more on temporarily maintaining a fork of a project as large as Firefox, and my Firefox development workflow some other day on my website.

Let the coding begin!

The easiest part was to support the HTMLLinkElement.relList.supports() API. I just had to add a new string literal for rel="monetization". This can be easily used to detect whether a browser supports Web Monetization. Feels good to see some quick progress - git commit!

During the earlier prototyping, I decided to implement the <link rel=monetization> support entirely in C++, as it would've been more performant and would easily allow low level communication with the WM agent. But after getting stuck at various times to reach a half working implementation, I asked some Mozilla engineers and Emilio advised me to try prototyping in JSM (a Mozilla dialect of JavaScript modules that can talk directly to privileged browser code). Let's say that turned out to be a much more delightful experience than fighting with the linker in C++! Funnily, 2 lines of JS had the same effect as 300 lines of C++ (this is not a language comparison, but related to Gecko's architecture).

The JSM approach required a change in thinking — from low level hyper-optimized stuff to high level design. Though, it felt weird to not have any type-checking/hinting support in the editor — I had to jump into WebIDL definitions to understand what JSM can do. Fast forward a few days, I had a working implementation of what's mentioned above (except CSP, which required a lot more fiddling across 18 files).

Creating a Nightly release

Satisfied with the current implementation, I created a Firefox Nightly release for you to try! You can find the download links in the wiki.

After extracting the downloaded archives, you need to run it from command line as:

./firefox --jsconsole

The --jsconsole flag opens Firefox with a "multi process browser console" window, which will display various Web Monetization metadata, logs and error messages.

Remaining activities

Next, I'll work towards bringing the actual Web Monetization support in Firefox. For this, we'll first need to specify the role of WM agent (browser extension) and the communication between the WM agent, browser, and the website. Once that's done, we'll hopefully have a working native implementation of Web Monetization. While we discuss and decide above, we'll try to formalize the specification based on the things we've learned so far.

We're already discussing the role of WM agent over GitHub. Feel free to join!

What community support would benefit your project?

I'm curious to understand how we should go with the monetization of iframes and other embedded content like images and videos. Say, you're the page owner, how do you think we should monetize third party content embedded in your site? Conversely, how would you like your content to be monetized if it's embedded in some other website? One idea that comes to mind is to only allow the visible content to be monetized as the user scrolls through the site, but it adds quite a lot of complexity to the browser and has many edge cases. Is this something you would love to see in the first version of the Web Monetization standard, or it can be deferred for later? Let us know what you think in comments below or at GitHub.

Additional comments

Thanks to the Grant for the Web for supporting my workstation purchase. I can't emphasize enough what a difference this has made to my development flow: I'm able to compile Gecko in record time - nearly 7 minutes, compared to 80 minutes on my previous laptop. This enabled me to quickly prototype various implementation strategies without wasting hours waiting for Gecko to compile!

Relevant links/resources

Implementation of Web Monetization in Mozilla Firefox:
- Code
- Downloads

Hello from the browser side

Sid Vishnoi — Sun, 22 Nov 2020 18:04:39 +0000

Hello! I'm Sid, an independent software developer and a technical scholar for Grant for the Web. I am exploring how Web Monetization can be integrated into a web browser, in this case, Mozilla Firefox. For Web Monetization to become viable, native support in browsers seems somewhat critical.

The goals of this project are two-fold:

Create a reference implementation of the Web Monetization specification in Gecko/Firefox (Desktop). This would allow the WM community to evaluate the implementability and feasibility of Web Monetization in a browser's engine. This would also allow the WM community to see what existing web infrastructure can be leveraged and also figure out if any new technology or protocols are needed - and things that may need to be standardized.
Verify the specification through implementation, which allows us to inform the standardization process (i.e., what is and isn’t feasible, as well as anything that might be under-specified).

Let me know in comments if you would like additional details on the scope of the project. In my next post, I'll share details on the progress we've made so far and where we're headed.

The Interledger Community 🌱: Sid Vishnoi

Memorable wallet addresses on your own domain

CityJS Singapore 2024 - Web Monetization extension demo booth

The Demo

Audience Perception of the Extension + WM

Concerns

Key Takeaways

Recommendations

Bringing Web Monetization to the Web Platform — Grant Report #2

Project Update

Progress on objectives

Key activities

Figure out Extension vs PaymentHandler

Define a minimal extension API

Understand how to develop an extension API in Firefox

Setup communication between extension, browser and websites

Implement the WebAPI

Write Usage Examples

Share feedback with WM community and Mozilla

Remaining activities

What community support would benefit your project?

Additional comments

Relevant links/resources

Browser Extension vs Payment Handler API

Browser Extension

Payment Handler API

The way forward

Summary

Exploring integration of Web Monetization into the Web Platform — Grant Report #1

Project Update

Progress on objectives

<link> is the way forward

Bringing it to the browser

Key activities

Initial research

Set up development environment

Let the coding begin!

Creating a Nightly release

Remaining activities

What community support would benefit your project?

Additional comments

Relevant links/resources

Hello from the browser side

`<link>` is the way forward