positiveblue

It’s wild, decades of work on least privilege and delegation, and we’re back to handing out root credentials to bots T.T

Adoption is definitely the hardest "cryptographic" problem :D

You can think about this as a new auth token to add in your stack. It does not need to grow and take over the world overnight. We have seen how hard it is to change the status quo + how much it can adapt to new ideas (ex: SQL vs NoSQL)

For now I would imagine teams who need more flexibility in their auth stack to adopt this for new API

Wafers are definitely inspired by Macaroons, but the core difference is that delegation is tied to identity.

In Macaroons, anyone who holds the token can tack on caveats.

In Wafers, only the current holder can extend it, and they can explicitly name the next holder by public key.

That gives you a verifiable chain of custody instead of an unanchored blob.

TLDR: JWTs say who you are. Wafers say who this request is on behalf of and exactly what it can do.

I could not give less of a shit between whitelist/allowlist. I use them indistinctly.

You can sleep peacefully today but you should try to don't over stress from how other people write on the internet

100% needs to be done at the last mile.

Hi, "this person here" Cloudflare will block that request that has a jwt because "it does not come from a person".

What I was trying to say is that even the discussion "is this a bot 100% sure or not" makes no sense.

many people don't remember/know history though

yep, that's why I am writing this now :)

You can see it in the web vs mobile apps.

Many people may not see a problem on wallet gardens but reality is that we have much less innovation in mobile than in web because anyone can spawn a web server vs publish an app in the App Store (apple)

I know the image, what I do not understand is the argument between using it being incompatible with "fairness" and "openness"

No

Where everyone needs a cloudflare account to be able to pay*

> An allowlist run by one company that site owners chose to engage with.

Exactly, no problem with that, just hinting that's not a protocol.

> But the irony of taking an ideological stance about fairness while using AI generated comics for blog posts

Wait, what?

The point is "should everyone just have an account with Cloudflare then"

This is one of the main points :+1:

I actually thought about this before publishing it hahaha

Good thing they are not the only place to post!

Narrator: but he did put effort...

Anyway, main take aways for you:

- We REALLY need a way to tie identity to agent/requests - The idea of registering with cloudflare to be able to access a website is bad - Sites should be able to block whoever they want or make anything they desire a requirement (there are people that has login only with google after all)

We have the right primitives to build something that works for any provider (from cloudflare, to Akamai, to self hosting nginx servers). Let's take that route

Giving an agent full access to your data without clear guardrails is a really bad idea.

We automate checkouts for e-commerce stores and work with very sensitive information, but our agents never see the real data. They only fill forms with placeholders, which later get swapped with the actual values downstream.

Prompt injection is a real risk, and while the industry will adapt, you need to be extremely cautious when letting agents operate in these contexts. Long story short: do not give "admin" privileges to AI Agents in the wild.

Well, the answer is "I do not know"

Now, if I had to guess, this are "a new kind of cookies" so they just took a name that went with it (like they did with biscuits https://www.biscuitsec.org/)

There are many chances that they got he name wrong and they meant Macaron (with one O instead of two). Those are "layered" cookies, which bring some resemblance on how "caveats" can be understood.

Unfortunately, that is so complex and changes so often that should not be implemented at protocol level, but around it.

P.S: I feel you :)

Disclaimer: I am the founder of Fewsats, former Lightning Labs employee and owner of the L402.org domain

I'd like to clarify a few points and add some context to the discussion.

1) Protocol: While the current implementation of the L402 flow uses macaroons for credentials and Lightning invoices for challenges, the protocol itself is agnostic to these specifics. As long as the challenge has a verifiable "proof of completion" and a way to identify the credentials, the L402 flow can work with other types of credentials and challenges.

2) Micropayments: While L402 supports micropayments, it's not limited to them. At Fewsats, we use L402 for subscription-based services with standard SaaS payment amounts, issuing macaroons with 1-month expiration dates.

3) Multi-currency support: The Lightning Network currently uses Bitcoin, but with the introduction of Taproot Assets (also from Lightning Labs), it will natively support other currencies like stablecoins (USDt?)

4) Open Protocols: The Lightning Network and L402 are open, decentralized protocols that anyone can use and integrate without depending on any specific third party. There's no native token, ICO, or controlling company, making comparisons to bankrupt entities irrelevant.

5) Network health: The Lightning Network has been operational for years and continues to grow and evolve, with developments like L402 and Taproot Assets enhancing its capabilities and utility I would say it's future looks better than ever.

If I forgot anything feel free to as me in a comment.

Well, paywall her can also mean any subscription or even credits-based system like SaaS or Compute APIs (AI inference for example) not only for content.