How does Delving Bitcoin compare to bitcoin stack exchange?

@darthcoin @Wumbo the question is more directed at protocol developments, such as trampoline, route blinding, and RGS, than tips/tricks for routers. Seems like these are all isolated topics

Interesting, I hadn't thought about using wireguard keys for signing the token, though I'm not sure what exactly is gained by doing so.

I mean no one else knows the preimage and holds the token: both are required by the server.

You're right, the server has to manage wireguard sessions so it can't be completely stateless, but my goal is to make the server as simple as possible. Both approaches should work, but when considering the trade-offs, I like pushing the logic and control to the client.

JWT gives "algorithm agility" while Paseto is designed to be easy-to-use securely: https://github.com/paseto-standard/paseto-spec#key-differences-between-paseto-and-jwt

Only the client knows the preimage and holds the security token, so no risk of someone stealing a session. Also, PTLCs would further mitigate that risk if my understanding is correct.

For an MVP, I don't plan to build roaming for a single token. If a user changes locations, they would start a new session and buy new tokens. Eventually, might be cool to have longer term tokens, so that a user can initiate a session without making a payment on clearnet

The prototype is time-based. But wireguard tracks data throughput, so a preffered option would be data-use model.

Managing everything on the server requires more central processing. The server has to store the 'contract' details for every open invoice and respond to every settled invoice. How well does this scale? If the server misses an invoice completion, how does it know to re-initiate? By moving state to the client, the server is (almost) stateless, only needing to handle client requests

An LSAT (aka L402) is simply a macaroon (same type as LND but different context) plus an invoice.

I used LSATs in the prototype implementation because there are already NodeJS libraries (lsat-js + Boltwall) that made it easy to set up. However, as I mention in the article, I think something like Paseto would be more appropriate because macaroons are not necessary. Paseto is more similar to a JWT; it's basically JSON data signed by the server. One of the fields would be the payment hash (hash of preimage). Upon payment, the user provides the preimage which the server can verify locally.

For this use case at least, I prefer putting the logic on the client-side because it puts the user in the driver seat. The user has a cryptographic proof-of-purchase that ties their preimage to the service its expecting. Although an MVP would be limited, it also gives the user the ability to activate tokens when and where they choose.

On the other hand, the server is dumb. All the server needs to do is fetch/generate an invoice and verify the token locally, which makes it much easier for service providers to spin up and down instances. I'm not sure if it's possible but it would be cool to generate invoices without fetching from a remote Lightning Node

Hell yeah Andy

The summary on the paywall should give you an idea of what's behind the paywall. The ratings and reviews are designed to give you a measure of content quality but unfortunately, the site doesn't have much usage

For anyone looking for a lightning paywall platform, checkout WordForm - https://wordform.space