15 sats \ 7 replies \ @TonyGiorgio 12 Oct 2023 \ on: Proxnut: #BuildinPublic getting up to speed bitcoin
Basically like LL's middleware aperture project but with ecash as the API token instead of macaroons?
Really interested to seeing this work. Anonymous paid API tokens is critical work IMO, if I'm understanding it correctly. Nice write up.
Yes! I think Very similar to LL's L402 but some nuanced differences.
Check this answer on the AMA post for more details:
#268791
reply
Interesting, yup I like it. I can see it working for some use cases better than others. Some things work well stateless, but some might not.
Could you reuse the ecash token if you need to meter or retain history?
Example: support requests
1 paid support request per month, so give out one ecash token that expires at end of month. However, once that token is used to open a new issue, they should be able to keep hitting the API call. I can see a few ways to handle this.
- Only block the "/support/new" call behind ecash
- Each successful redemption will return a response containing a new ecash token
- Turn ecash into jwt to track / meter things once consumed
Either of those three ways would accomplish something I do find special about using ecash as an API token: cuts off source of identity from the original acquisition of the ecash, even if you need to associate after first consumption.
reply
I think you could definitely hack something like that, but IMO as soon as you strart to introduce statefulness, other protocols start to make more sense.
Therfore, In the above example, i like number 3 the most, it leverages another protocol that is great for managing state
Ecash is kinda inherently stateless, because links get broken after every token creation. So you would have to manually upkeep that state somehow, which kinda defeats the purpose.
But I think that's OK, because there are other things (like L402, JWT, etc..) that handle state well!
wow, i said state so many times....
We need to separate the web from the state
reply
One thing worth mentioning, the complexity of a stateless system is just so much lower than a stateful one, that it makes sense from an engineering perspective to consider if state is really necessary or if it's just an excuse to track users :P
But of course, sometimes you definitely need state/accounts/users , in which case PROXNUT may not help much
reply
Thanks for the feedback!
I know a few companies in the space looking for something that I've described above so I appreciate your thoughts there. I do like method 3 as well and like that ecash API tokens would still be useful even if it is not being used for a forward-looking privacy preserving method, for state requirement reasons.
reply
appreciate your insights too!
reply
Only block the "/support/new" call behind ecash Each successful redemption will return a response containing a new ecash token Turn ecash into jwt to track / meter things once consumed Either of those three ways would accomplish something I do find special about using ecash as an API token: cuts off source of identity from the original acquisition of the ecash, even if you need to associate after first consumption.
Ecash is perfect for this. You don't even need to recycle once. If you buy it with a payment (or some other "proof of humanity" or something), you can use it immediately (and privately). Ecash systems without the ability to transact between users definitely has applications people are interested in (such as resource access control).
reply