#webmonetization — Public Fediverse posts

@rstockm „Dezentrales Flattr“? Finde @Taler und #WebMonetization von @Interledger sind interessante Elemente dafür.

Looks like Chimoney has shut down.

Bad news for @Interledger and #WebMonetization

Lighting a virtual candle in remembrance of Coil today.

🕯️🕯️🕯️

I look forward to the day when we all get off that waitlist.

#WebMonetization

Web Monetization is now available in Google’s Offerwall 🎉

Publishers can offer it alongside ads or surveys, giving users a direct way to support content through micropayments 🌱

Curious how it works?
Read more: https://interledger.org/news/web-monetization-meets-googles-offerwall

#WebMonetization #OpenWeb #Interledger

🎤 Protocols for Publishers Lightning Talk

In this recorded talk, @Jeremiah, (Interledger Foundation Grant Program Officer & Tech Lead) explores why journalism must test new models powered by instant, interoperable payments.

What if readers could support journalism directly, no ads, no paywalls, no gatekeepers?

🎥 Watch here:
https://youtu.be/kwu8ELIa8B0

#Interledger #WebMonetization #FinancialInclusion #TechForGood

If you are around the Greater #Vancouver Area (Canada) I’d love to invite you to join the #vanjs (Vancouver JavaScript) meetup. My colleague Bibi Souza will be hosting the event and talking about #WebMonetization!
https://luma.com/dk641anc

If you are around the Greater #Vancouver Area (Canada) I’d love to invite you to join the #vanjs (Vancouver JavaScript) meetup. My colleague Bibi Souza will be hosting the event and talking about #WebMonetization!
https://luma.com/dk641anc

If you are around the Greater #Vancouver Area (Canada) I’d love to invite you to join the #vanjs (Vancouver JavaScript) meetup. My colleague Bibi Souza will be hosting the event and talking about #WebMonetization!
https://luma.com/dk641anc

If you are around the Greater #Vancouver Area (Canada) I’d love to invite you to join the #vanjs (Vancouver JavaScript) meetup. My colleague Bibi Souza will be hosting the event and talking about #WebMonetization!
https://luma.com/dk641anc

"We need far more than a different PayFac or a different Itch. We need an entire different way of transferring funds online.

But I still hate crypto."

#interledger #GNUtaler #WebMonetization #OpenPayments #FediForFiat

https://voidfox.com/blog/payment_processor_fun_2025_making_your_own_msp/

@IanTwenty @Edent

There is one exchange active: https://taler-ops.ch/en/index.html

For #WebMonetization I'm aware of only three wallet providers. Only one available in Switzerland.

Actually I'd love to have an open interface with multiple options, so that creators can have multiple options for their supporters to choose from. Then I can have e.g. #Librapay WebMonetization, and #GNUTaler, while @blog might prefer e.g. Paypal, and Bitcoin, etc.

That fits the #fediverse best.

As I was researching (again) #WebMonetization for the blogs, and didn't like the 3 available "Wallet" options, for myself and users visiting, I went back to "Buy me a Coffee" and created a simple membership tier: €1 / month.
https://buymeacoffee.com/cybeardjm/membership

Grant for the Web to Make the Fediverse More Sustainable, Democratic, and Fun

https://socialwebfoundation.org/2026/02/04/grant-for-the-web-to-make-the-fediverse-more-sustainable-democratic-and-fun/

How do #interledger and #GNUTaler differ?

We need federated fiat. Trusted banks or credit unions acting like servers. Apps that let you send money as easily as we send email today, without a middleman. Enabling us to build cool programs that connect to other services, like paying creators for the time we spend with their work. But doing all this without the problems of crypto, just like we don't keep all our money in cash under the mattress.

#FediForFiat #WebMonetization #OpenPayments

Last year at #FOSDEM, I met with @pfefferle about hooks in @activitypub.blog in order for @Interledger’s Web Monetization plugin to add wallet addresses to profiles and posts.

A year later, it’s reality! 🙌

https://wordpress.org/plugins/interledger-web-monetization-integration/

#WebMonetization

🆕 blog! “Responsible Disclosure: Chimoney Android App and KYCaid”

Chimoney is a new "multi-currency wallet" provider. Based out of Canada, it allows users to send money to and from a variety of currencies. It also supports the new Interledger protocol for WebMonetization.

But it has a security flaw which cannot be ignored.

👀 Read more: https://shkspr.mobi/blog/2026/01/responsible-disclosure-chimoney-android-app-and-kycaid/
⸻
#android #CyberSecurity #ResponsibleDisclosure #security #WebMonetization

🆕 blog! “Responsible Disclosure: Chimoney Android App and KYCaid”

Chimoney is a new "multi-currency wallet" provider. Based out of Canada, it allows users to send money to and from a variety of currencies. It also supports the new Interledger protocol for WebMonetization.

But it has a security flaw which cannot be ignored.

👀 Read more: https://shkspr.mobi/blog/2026/01/responsible-disclosure-chimoney-android-app-and-kycaid/
⸻
#android #CyberSecurity #ResponsibleDisclosure #security #WebMonetization

🆕 blog! “Responsible Disclosure: Chimoney Android App and KYCaid”

Chimoney is a new "multi-currency wallet" provider. Based out of Canada, it allows users to send money to and from a variety of currencies. It also supports the new Interledger protocol for WebMonetization.

But it has a security flaw which cannot be ignored.

👀 Read more: https://shkspr.mobi/blog/2026/01/responsible-disclosure-chimoney-android-app-and-kycaid/
⸻
#android #CyberSecurity #ResponsibleDisclosure #security #WebMonetization

🆕 blog! “Responsible Disclosure: Chimoney Android App and KYCaid”

Chimoney is a new "multi-currency wallet" provider. Based out of Canada, it allows users to send money to and from a variety of currencies. It also supports the new Interledger protocol for WebMonetization.

But it has a security flaw which cannot be ignored.

👀 Read more: https://shkspr.mobi/blog/2026/01/responsible-disclosure-chimoney-android-app-and-kycaid/
⸻
#android #CyberSecurity #ResponsibleDisclosure #security #WebMonetization

🆕 blog! “Responsible Disclosure: Chimoney Android App and KYCaid”

Chimoney is a new "multi-currency wallet" provider. Based out of Canada, it allows users to send money to and from a variety of currencies. It also supports the new Interledger protocol for WebMonetization.

But it has a security flaw which cannot be ignored.

👀 Read more: https://shkspr.mobi/blog/2026/01/responsible-disclosure-chimoney-android-app-and-kycaid/
⸻
#android #CyberSecurity #ResponsibleDisclosure #security #WebMonetization

Responsible Disclosure: Chimoney Android App and KYCaid

Chimoney is a new "multi-currency wallet" provider. Based out of Canada, it allows users to send money to and from a variety of currencies. It also supports the new Interledger protocol for WebMonetization.

It is, as far as I can tell, unregulated by any financial institution. Nevertheless, it performs a "Know Your Customer" (KYC) check on all new account in order to prevent fraud. To do this, it uses the Ukranian KYCaid platform.

So far, so standard. But there's a small problem with how they both integrate.

I installed Chimoney's Android app and attempted to go through KYCaid's verification process. For some reason it hit me with this error message.

Well, I'd better click that email and report the problem.

Oh, that's odd. What happens if I click the protected link?

Huh! I guess I've been taken to Cloudflare's website. What happens if I click on the links on their page?

Looks like I can now visit any site on the web. If Cloudflare has a link to it, I can go there. For example, GitHub.

Why is this a problem?

MASTG-KNOW-0018: WebViews

One of the most important things to do when testing WebViews is to make sure that only trusted content can be loaded in it. Any newly loaded page could be potentially malicious, try to exploit any WebView bindings or try to phish the user. Unless you're developing a browser app, usually you'd like to restrict the pages being loaded to the domain of your app. A good practice is to prevent the user from even having the chance to input any URLs inside WebViews (which is the default on Android) nor navigate outside the trusted domains. Even when navigating on trusted domains there's still the risk that the user might encounter and click on other links to untrustworthy content

Emphasis added

A company's app is its sacred space. It shouldn't let anyone penetrate its inner sanctum because it has no control over what that 3rd party shows its customers.

There's nothing stopping an external service displaying a message like "To continue, please transfer 0.1 Bitcon to …"

(Of course, if your KYC provider - or their CDN - decides to turn evil then you probably have bigger problems!)

There are some other problems. It has long been known that people can use in-app browsers to circumvent restrictions. Some in-app browsers have insecure configurations which can be used for exploits. These sorts of "accidentally open" browsers are often considered to be a security vulnerability.

The Fix

Ideally, an Android app like this wouldn't use a web view. It should use a KYC provider's API rather than giving them wholesale control of the user experience.

But, suppose you do need a webview. What's the recommendation?

Boring old URl validation using Android's shouldOverrideUrlLoading() method.

Essentially, your app restricts what can be seen in the webview and rejects anything else.

Risk

Look, this is pretty low risk. A user would have to take several deliberate steps to find themselves in a place of danger.

Ultimately, it is "Code Smell" - part of the app is giving off a noxious whiff. That's something you cannot afford to have on a money transfer app. If this simple security fix wasn't implemented, what other horrors are lurking in the source code?

Contacting the company

There was no security.txt contact - nor anything on their website about reporting security bugs. I reached out to the CEO by email, but didn't hear back.

In desperation, I went on to Discord and asked in their support channel for help.

Unfortunately, that email address didn't exist.

I also tried contacting KYCaid, but they seemed unable or unwilling to help - and redirected me back to Chimoney.

As it has been over two month since I sent them video of this bug, I'm performing a responsible disclosure to make people aware of the problem.

Responsible Disclosure: Chimoney Android App and KYCaid

Chimoney is a new "multi-currency wallet" provider. Based out of Canada, it allows users to send money to and from a variety of currencies. It also supports the new Interledger protocol for WebMonetization.

It is, as far as I can tell, unregulated by any financial institution. Nevertheless, it performs a "Know Your Customer" (KYC) check on all new account in order to prevent fraud. To do this, it uses the Ukranian KYCaid platform.

So far, so standard. But there's a small problem with how they both integrate.

I installed Chimoney's Android app and attempted to go through KYCaid's verification process. For some reason it hit me with this error message.

Well, I'd better click that email and report the problem.

Oh, that's odd. What happens if I click the protected link?

Huh! I guess I've been taken to Cloudflare's website. What happens if I click on the links on their page?

Looks like I can now visit any site on the web. If Cloudflare has a link to it, I can go there. For example, GitHub.

Why is this a problem?

MASTG-KNOW-0018: WebViews

One of the most important things to do when testing WebViews is to make sure that only trusted content can be loaded in it. Any newly loaded page could be potentially malicious, try to exploit any WebView bindings or try to phish the user. Unless you're developing a browser app, usually you'd like to restrict the pages being loaded to the domain of your app. A good practice is to prevent the user from even having the chance to input any URLs inside WebViews (which is the default on Android) nor navigate outside the trusted domains. Even when navigating on trusted domains there's still the risk that the user might encounter and click on other links to untrustworthy content

Emphasis added

A company's app is its sacred space. It shouldn't let anyone penetrate its inner sanctum because it has no control over what that 3rd party shows its customers.

There's nothing stopping an external service displaying a message like "To continue, please transfer 0.1 Bitcon to …"

(Of course, if your KYC provider - or their CDN - decides to turn evil then you probably have bigger problems!)

There are some other problems. It has long been known that people can use in-app browsers to circumvent restrictions. Some in-app browsers have insecure configurations which can be used for exploits. These sorts of "accidentally open" browsers are often considered to be a security vulnerability.

The Fix

Ideally, an Android app like this wouldn't use a web view. It should use a KYC provider's API rather than giving them wholesale control of the user experience.

But, suppose you do need a webview. What's the recommendation?

Boring old URl validation using Android's shouldOverrideUrlLoading() method.

Essentially, your app restricts what can be seen in the webview and rejects anything else.

Risk

Look, this is pretty low risk. A user would have to take several deliberate steps to find themselves in a place of danger.

Ultimately, it is "Code Smell" - part of the app is giving off a noxious whiff. That's something you cannot afford to have on a money transfer app. If this simple security fix wasn't implemented, what other horrors are lurking in the source code?

Contacting the company

There was no security.txt contact - nor anything on their website about reporting security bugs. I reached out to the CEO by email, but didn't hear back.

In desperation, I went on to Discord and asked in their support channel for help.

Unfortunately, that email address didn't exist.

I also tried contacting KYCaid, but they seemed unable or unwilling to help - and redirected me back to Chimoney.

As it has been over two month since I sent them video of this bug, I'm performing a responsible disclosure to make people aware of the problem.

Responsible Disclosure: Chimoney Android App and KYCaid

Chimoney is a new "multi-currency wallet" provider. Based out of Canada, it allows users to send money to and from a variety of currencies. It also supports the new Interledger protocol for WebMonetization.

It is, as far as I can tell, unregulated by any financial institution. Nevertheless, it performs a "Know Your Customer" (KYC) check on all new account in order to prevent fraud. To do this, it uses the Ukranian KYCaid platform.

So far, so standard. But there's a small problem with how they both integrate.

I installed Chimoney's Android app and attempted to go through KYCaid's verification process. For some reason it hit me with this error message.

Well, I'd better click that email and report the problem.

Oh, that's odd. What happens if I click the protected link?

Huh! I guess I've been taken to Cloudflare's website. What happens if I click on the links on their page?

Looks like I can now visit any site on the web. If Cloudflare has a link to it, I can go there. For example, GitHub.

Why is this a problem?

MASTG-KNOW-0018: WebViews

One of the most important things to do when testing WebViews is to make sure that only trusted content can be loaded in it. Any newly loaded page could be potentially malicious, try to exploit any WebView bindings or try to phish the user. Unless you're developing a browser app, usually you'd like to restrict the pages being loaded to the domain of your app. A good practice is to prevent the user from even having the chance to input any URLs inside WebViews (which is the default on Android) nor navigate outside the trusted domains. Even when navigating on trusted domains there's still the risk that the user might encounter and click on other links to untrustworthy content

Emphasis added

A company's app is its sacred space. It shouldn't let anyone penetrate its inner sanctum because it has no control over what that 3rd party shows its customers.

There's nothing stopping an external service displaying a message like "To continue, please transfer 0.1 Bitcon to …"

(Of course, if your KYC provider - or their CDN - decides to turn evil then you probably have bigger problems!)

There are some other problems. It has long been known that people can use in-app browsers to circumvent restrictions. Some in-app browsers have insecure configurations which can be used for exploits. These sorts of "accidentally open" browsers are often considered to be a security vulnerability.

The Fix

Ideally, an Android app like this wouldn't use a web view. It should use a KYC provider's API rather than giving them wholesale control of the user experience.

But, suppose you do need a webview. What's the recommendation?

Boring old URl validation using Android's shouldOverrideUrlLoading() method.

Essentially, your app restricts what can be seen in the webview and rejects anything else.

Risk

Look, this is pretty low risk. A user would have to take several deliberate steps to find themselves in a place of danger.

Ultimately, it is "Code Smell" - part of the app is giving off a noxious whiff. That's something you cannot afford to have on a money transfer app. If this simple security fix wasn't implemented, what other horrors are lurking in the source code?

Contacting the company

There was no security.txt contact - nor anything on their website about reporting security bugs. I reached out to the CEO by email, but didn't hear back.

In desperation, I went on to Discord and asked in their support channel for help.

Unfortunately, that email address didn't exist.

I also tried contacting KYCaid, but they seemed unable or unwilling to help - and redirected me back to Chimoney.

As it has been over two month since I sent them video of this bug, I'm performing a responsible disclosure to make people aware of the problem.

Responsible Disclosure: Chimoney Android App and KYCaid

Chimoney is a new "multi-currency wallet" provider. Based out of Canada, it allows users to send money to and from a variety of currencies. It also supports the new Interledger protocol for WebMonetization.

It is, as far as I can tell, unregulated by any financial institution. Nevertheless, it performs a "Know Your Customer" (KYC) check on all new account in order to prevent fraud. To do this, it uses the Ukranian KYCaid platform.

So far, so standard. But there's a small problem with how they both integrate.

I installed Chimoney's Android app and attempted to go through KYCaid's verification process. For some reason it hit me with this error message.

Well, I'd better click that email and report the problem.

Oh, that's odd. What happens if I click the protected link?

Huh! I guess I've been taken to Cloudflare's website. What happens if I click on the links on their page?

Looks like I can now visit any site on the web. If Cloudflare has a link to it, I can go there. For example, GitHub.

Why is this a problem?

MASTG-KNOW-0018: WebViews

One of the most important things to do when testing WebViews is to make sure that only trusted content can be loaded in it. Any newly loaded page could be potentially malicious, try to exploit any WebView bindings or try to phish the user. Unless you're developing a browser app, usually you'd like to restrict the pages being loaded to the domain of your app. A good practice is to prevent the user from even having the chance to input any URLs inside WebViews (which is the default on Android) nor navigate outside the trusted domains. Even when navigating on trusted domains there's still the risk that the user might encounter and click on other links to untrustworthy content

Emphasis added

A company's app is its sacred space. It shouldn't let anyone penetrate its inner sanctum because it has no control over what that 3rd party shows its customers.

There's nothing stopping an external service displaying a message like "To continue, please transfer 0.1 Bitcon to …"

(Of course, if your KYC provider - or their CDN - decides to turn evil then you probably have bigger problems!)

There are some other problems. It has long been known that people can use in-app browsers to circumvent restrictions. Some in-app browsers have insecure configurations which can be used for exploits. These sorts of "accidentally open" browsers are often considered to be a security vulnerability.

The Fix

Ideally, an Android app like this wouldn't use a web view. It should use a KYC provider's API rather than giving them wholesale control of the user experience.

But, suppose you do need a webview. What's the recommendation?

Boring old URl validation using Android's shouldOverrideUrlLoading() method.

Essentially, your app restricts what can be seen in the webview and rejects anything else.

Risk

Look, this is pretty low risk. A user would have to take several deliberate steps to find themselves in a place of danger.

Ultimately, it is "Code Smell" - part of the app is giving off a noxious whiff. That's something you cannot afford to have on a money transfer app. If this simple security fix wasn't implemented, what other horrors are lurking in the source code?

Contacting the company

There was no security.txt contact - nor anything on their website about reporting security bugs. I reached out to the CEO by email, but didn't hear back.

In desperation, I went on to Discord and asked in their support channel for help.

Unfortunately, that email address didn't exist.

I also tried contacting KYCaid, but they seemed unable or unwilling to help - and redirected me back to Chimoney.

As it has been over two month since I sent them video of this bug, I'm performing a responsible disclosure to make people aware of the problem.

Responsible Disclosure: Chimoney Android App and KYCaid

Chimoney is a new "multi-currency wallet" provider. Based out of Canada, it allows users to send money to and from a variety of currencies. It also supports the new Interledger protocol for WebMonetization.

It is, as far as I can tell, unregulated by any financial institution. Nevertheless, it performs a "Know Your Customer" (KYC) check on all new account in order to prevent fraud. To do this, it uses the Ukranian KYCaid platform.

So far, so standard. But there's a small problem with how they both integrate.

I installed Chimoney's Android app and attempted to go through KYCaid's verification process. For some reason it hit me with this error message.

Well, I'd better click that email and report the problem.

Oh, that's odd. What happens if I click the protected link?

Huh! I guess I've been taken to Cloudflare's website. What happens if I click on the links on their page?

Looks like I can now visit any site on the web. If Cloudflare has a link to it, I can go there. For example, GitHub.

Why is this a problem?

MASTG-KNOW-0018: WebViews

One of the most important things to do when testing WebViews is to make sure that only trusted content can be loaded in it. Any newly loaded page could be potentially malicious, try to exploit any WebView bindings or try to phish the user. Unless you're developing a browser app, usually you'd like to restrict the pages being loaded to the domain of your app. A good practice is to prevent the user from even having the chance to input any URLs inside WebViews (which is the default on Android) nor navigate outside the trusted domains. Even when navigating on trusted domains there's still the risk that the user might encounter and click on other links to untrustworthy content

Emphasis added

A company's app is its sacred space. It shouldn't let anyone penetrate its inner sanctum because it has no control over what that 3rd party shows its customers.

There's nothing stopping an external service displaying a message like "To continue, please transfer 0.1 Bitcon to …"

(Of course, if your KYC provider - or their CDN - decides to turn evil then you probably have bigger problems!)

There are some other problems. It has long been known that people can use in-app browsers to circumvent restrictions. Some in-app browsers have insecure configurations which can be used for exploits. These sorts of "accidentally open" browsers are often considered to be a security vulnerability.

The Fix

Ideally, an Android app like this wouldn't use a web view. It should use a KYC provider's API rather than giving them wholesale control of the user experience.

But, suppose you do need a webview. What's the recommendation?

Boring old URl validation using Android's shouldOverrideUrlLoading() method.

Essentially, your app restricts what can be seen in the webview and rejects anything else.

Risk

Look, this is pretty low risk. A user would have to take several deliberate steps to find themselves in a place of danger.

Ultimately, it is "Code Smell" - part of the app is giving off a noxious whiff. That's something you cannot afford to have on a money transfer app. If this simple security fix wasn't implemented, what other horrors are lurking in the source code?

Contacting the company

There was no security.txt contact - nor anything on their website about reporting security bugs. I reached out to the CEO by email, but didn't hear back.

In desperation, I went on to Discord and asked in their support channel for help.

Unfortunately, that email address didn't exist.

I also tried contacting KYCaid, but they seemed unable or unwilling to help - and redirected me back to Chimoney.

As it has been over two month since I sent them video of this bug, I'm performing a responsible disclosure to make people aware of the problem.

Our first monthly community call of the year will be on Wednesday, January 14.

Join us for a first look at the foundation’s 2026 plans for advancing digital financial inclusion, #OpenPayments, and #WebMonetization.

https://community.interledger.org/interledger/join-us-for-the-interledger-community-call-14-january-2026-4fn0?ref=activitypub

@raymondcamden I fail to read between the lines if this is sarcastic, ironic, or literal. Sorry for the direct question, but as someone interested in #WebMonetization (https://blog.tomayac.com/2025/11/07/using-the-web-monetization-api-for-fun-and-profit/), I'm honestly hoping to understand if ads work for personal/indie blogs like yours.

Curious how Web Monetization uses #OpenPayments?

Part 1 of our new series breaks down the basics, the browser extension, wallet setup, budgets, and how creators get supported behind the scenes.

👉 Read Part 1 by Sid Vishnoi: https://interledger.org/developers/blog/web-monetization-open-payments-part-1-connecting-wallet/

#WebMonetization #OpenPayments

Web Monetization is Still Inching Along, But Still Too Difficult

https://web.brid.gy/r/https://frontendmasters.com/blog/web-monetization-is-still-inching-along-but-still-too-difficult/

A theory has occurred to me as I woke up (probably irrational but I'll voice it anyway, just to get it out of my head)

I have an Uphold account from when the coil Web Monetization thing was running. They recently moved from allowing standards based 2FA (TOTP) to mandating installing their mobile app to sign in even on the web.

My first thought was that this was an information grab, but now wondering if it is also to stop people cashing out during a price crash

#coil #WebMonetization #2FA

📢 New blog post! Using the Web Monetization API for fun 🤩
and profit 🤑:

🔗 https://blog.tomayac.com/2025/11/07/using-the-web-monetization-api-for-fun-and-profit/

Learn how I use the proposed #WebMonetization standard by the @Interledger Foundation on my blog to (hopefully) pay for my virtual private server! The whole secret is this tag:

```html
<link rel="monetization" href="https://ilp.gatehub.net/348218105/eur" />
```

Công cụ AI mới Brambles.ai giúp website tự động tạo doanh thu liên kết. Nó nhận diện sản phẩm trong nội dung, kết nối với ưu đãi liên kết tốt nhất, loại bỏ quảng cáo truyền thống và quy trình thủ công. Hứa hẹn không thiên vị và không quảng cáo.
#AI #AffiliateMarketing #SideProject #WebMonetization #NoBias #TechNews
#TiếpThịLiênKết #DựÁnPhụ #KiếmTiềnWeb #KhôngThiênVị #TinTứcCôngNghệ

https://www.reddit.com/r/SideProject/comments/1omu52l/i_built_an_ai_chat_tool_that_helps_websites_earn/

@ricmac

the incentives are to create content for big tech platforms. to work for them. to get promoted by their algos and paid by them. we have a fedi coming together re an fair playing field for discovery, but we all need to come together to make #WebMonetization happen too. #PublicPatron

Holy shit you guys!

Someone at Meta remembered that #OpenGraphProtocol exists.

An update was made in June - https://github.com/facebook/open-graph-protocol/commits/master/

Which adds Payment link metadata - https://ogp.me/#type_payment

Nothing about #WebMonetization, sadly, but good to know the project isn't completely abandoned.

Holy shit you guys!

Someone at Meta remembered that #OpenGraphProtocol exists.

An update was made in June - https://github.com/facebook/open-graph-protocol/commits/master/

Which adds Payment link metadata - https://ogp.me/#type_payment

Nothing about #WebMonetization, sadly, but good to know the project isn't completely abandoned.

Holy shit you guys!

Someone at Meta remembered that #OpenGraphProtocol exists.

An update was made in June - https://github.com/facebook/open-graph-protocol/commits/master/

Which adds Payment link metadata - https://ogp.me/#type_payment

Nothing about #WebMonetization, sadly, but good to know the project isn't completely abandoned.

Holy shit you guys!

Someone at Meta remembered that #OpenGraphProtocol exists.

An update was made in June - https://github.com/facebook/open-graph-protocol/commits/master/

Which adds Payment link metadata - https://ogp.me/#type_payment

Nothing about #WebMonetization, sadly, but good to know the project isn't completely abandoned.

Holy shit you guys!

Someone at Meta remembered that #OpenGraphProtocol exists.

An update was made in June - https://github.com/facebook/open-graph-protocol/commits/master/

Which adds Payment link metadata - https://ogp.me/#type_payment

Nothing about #WebMonetization, sadly, but good to know the project isn't completely abandoned.

@Sascha @teezeh hat schon jemand Erfahrung mit #webmonetization?
Beeabee sieht so aus, als ob es nicht mehr gepflegt wird. Die Links zum Impressum etc sind tot.

@wjmaggos was going to boost that till I read the #WebMonetization hashtag, need some clarification on that bit :)

Most of the money that gets donated to political campaigns, gets spent on advertising. Getting people off media distribution systems with ads and instead funding the work directly, would do so much to fix our political process.

It's a huge part of why I want the #SocialWeb and #WebMonetization to win.

#DemocracyOfReach #PublicPatron

What if you could pay the same for media but have the money only go directly to the creators whose work you spent the most time with? That should be possible with decentralized social media and a protocol for bank to bank fiat transfers. If we gave enough, they'd tear down the paywalls themselves.

#SocialWeb #WebMonetization #PublicPatron

🌍 Foursquare isn’t just a map — it’s a data-driven platform for discovery and engagement.

This Snipesearch Adclicks feature explains how publishers can claim listings, link their sites, and earn from every visit using Adclicks.

Read here 👉

https://adclicks.thereview.website/monetising-the-foursquare-ecosystem/

#Foursquare #Adclicks #Snipesearch #WebMonetization #Publishing

Web Monetization via community.lexicon.payments.webMonetization records. Add your payment pointer in Settings → visitors with WM browsers stream you micropayments. Shout out to @snarfed.org, @lexicon.community, and @piss.beauty. #ATProtocol #WebMonetization

RE: https://bsky.app/profile/did:web:atwork.place/post/3m2ssogz3gs2j

🌍 Focus.xyz redefines what a crypto social platform can do for publishers. This feature explores how blockchain-backed identity and Creator Coin 2 connect social engagement with revenue.

💰 See how Adclicks bridges Focus traffic and on-site profit.

👉 https://adclicks.thereview.website/focus-xyz-driving-traffic-and-revenue-on-a-crypto-social-network/

#FocusXYZ #DeSo #Adclicks #WebMonetization #CreatorEconomy

Meet us at @[email protected] / @[email protected] in New York City!

Together with @avolakatos and Marian Villa, we will be around to chat more about #WebMonetization, #OpenPayments, #Interledger and the @interledger mission!
Come say hi!

#DemocracyOfReach project ideas:

#FediFBNextDoor - comfy communities for normies

#FediOGTwitter - it's not microblogging, it's a news feed

#FediPodcasts - AP instead of RSS would make them social

#FediReader - articles and text to speech

#FediYouTube - places for all peertube + owncast content

#FediSpotify - separate artist sites w unified streaming

#FediRadio - indy w chat

#WebMonetization - fiat protocol

#PublicPatron - pay what you can afford based on time spent with their work

🆕 blog! “Security Flaws in the WebMonetization Site”

I've written before about the nascent WebMonetization Standard. It is a proposal which allows websites to ask users for passive payments when they visit. A visitor to this site could, if this standard is widely adopted, opt to send me cash for my very fine blog…

👀 Read more: https://shkspr.mobi/blog/2025/08/security-flaws-in-the-webmonetization-site/
⸻
#BugBounty #CyberSecurity #ResponsibleDisclosure #WebMonetization #xss

Security Flaws in the WebMonetization Site

https://shkspr.mobi/blog/2025/08/security-flaws-in-the-webmonetization-site/

I've written before about the nascent WebMonetization Standard. It is a proposal which allows websites to ask users for passive payments when they visit. A visitor to this site could, if this standard is widely adopted, opt to send me cash for my very fine blog posts.

All I need to do is add something like this into my site's source code:

<link rel="monetization" href="https://wallet.example.com/edent">

A user who has a WebMonetization plugin can then easily pay me for my content.

But not every website is created by an individual or a single entity. Hence, the creation of the "Probabilistic Revenue Share Generator".

Probabilistic revenue sharing is a way to share a portion of a web monetized page's earnings between multiple wallet addresses. Each time a web monetized user visits the page, a recipient will be chosen at random. Payments will go to the chosen recipient until the page is closed or reloaded.

Nifty! But how does it work?

Let's say a website is created by Alice and Bob. Alice does most of the work and is to receive 70% of the revenue. Bob is to get the remaining 30%. Within the web page's head, the following meta element is inserted:

<link   rel="monetization"   href="https://webmonetization.org/api/revshare/pay/W1siaHR0cHM6Ly9leGFtcGxlLmNvbS8iLDcwLCJBbGljZSJdLFsiaHR0cHM6Ly93aGF0ZXZlci50ZXN0LyIsMzAsIkJvYiJdXQ"/>

The visitor's WebMonetization plugin will visit that URl and be redirected to Alice's site 70% of time and Bob's 30%.

If we Base64 decode that weird looking URl, we get:

[   [      "https://example.com/",       70,      "Alice"   ],   [      "https://whatever.test/",       30,      "Bob"   ]]

Rather than adding multiple URls in the head, the site points to one resource and lets that pick who receives the funds.

There are two small problems with this.

The first is that you have to trust the WebMonetization.org website. If it gets hijacked or goes rogue then all your visitors will be paying someone else. But let's assume they're secure and trustworthy. There's a slightly more insidious threat.

Effectively, this allows an untrusted 3rd party to use the WebMonetization.org domain as an open redirect. That's useful for phishing and other abuses.

For example, an attacker could send messages encouraging people to visit:

https://webmonetization.org/api/revshare/pay/W1siaHR0cHM6Ly9leGFtcGxlLmNvbS8iLDk5LCJpbWciXV0

Click that and you'll instantly be redirected to a domain under the attacker's control. This could be particularly bad if the domain encouraged users to share passwords or other sensitive information.

If the Base64 data cannot be decoded to valid JSON, the API will echo back any Base64 encoded text sent to it. This means an attacker could use it to send obfuscated messages. Consider, tor example:

https://webmonetization.org/api/revshare/pay/W1siUGxlYXNlIHZpc2l0IFJlYWxfZ29vZF9DYXNpbm9zLmJpeiBmb3IgbG90cyBvZiBDcnlwdG8gZnVuISEhIiwxMjM0NTYsImltZyJdXQ==

Visit that and you'll see a message. With a bit of effort, it could be crafted to say something to encourage a visitor to enter their credentials elsewhere.

When I originally reported this, the site could be used to to smuggle binary payloads. For example, this URl would display an image - however, it seems to have been fixed.

Nevertheless, it is important to recognise that the WebMonetization.org domain contains an unvalidated redirect and forwarding vulnerability.

I recommended that they ensured that the only URls which contain legitimate payment pointers should be returned. I also suggested setting a maximum limit for URl size.

Timeline

• 2025-03-27 - Discovered and disclosed.
• 2025-08-05 - Remembered I'd submitted it and sent a follow up.
• 2025-08-26 - Automatically published.
• 2025-08-27 - A day after this post was published, the issue was made public on their repo.
• 2025-09-10 - Confirmed fixed.

#BugBounty #CyberSecurity #ResponsibleDisclosure #WebMonetization #xss

Stay Updated with the Latest Developments

Web Monetization is evolving, and we’re excited to share new features, improvements, and success stories. Be the first to learn about innovative use cases, industry trends, and opportunities to grow with the ecosystem.

📩 Subscribe to our Newsletter for the latest technical releases and community updates: https://interledger.org/subscribe

#WebMonetization #Interledger #StayUpdated