[_3jh0]

Here's the thing though.

Let's say, I want to provide special benefit to people who own membership on hackernews.

In the model where this data is public, I can query the wallet of people to check for HN nft and provide special discount or perks.

If this membership data was privately backed up, I cannot do that.

It fits nicely into the blockchain model, imo.

Subscriber owns the membership and can prove to the service provider.

Service provider has access to the membership and can check the validity.

[csmpltn]

> "In the model where this data is public, I can query the wallet of people to check for HN nft and provide special discount or perks."

How will you provide your "perks" if either you or your members have been kicked off the platform where those perks made sense in the first place?

With this use-case you're describing - all you have is a list of wallets that were at some point relevant to you in some way. This is the equivalent of maintaining a mailing list. Why does any of this require a distributed ledger? What problem does this solve exactly?

> "Subscriber owns the membership and can prove to the service provider. Service provider has access to the membership and can check the validity."

How is this any different than signing up with an email-address as a username?

[_3jh0]

I think you are misunderstanding something above.

I'm not the one providing HN membership. That would be YC but I as a third party can verify whether someone has a valid HN membership and provide them perks based on their membership. That is the problem a distributed ledger solves. The data is public and usable by any service provider.

To verify you have a HN account (membership) today, a service provider need to build something like keybase. That is complicated and will be different for each service.

That is the problem unlock-protocol "solves". It defines the protocol for managing these memberships. To create, verify, deploy, etc.

You need some way to pay for membership without a middleman. This is solved by cryptocurrency part of the blockchain these nfts are stored on.

Memberships are also more complicated than a list of email addresses. They can be transferred, expired, and change depending on the action of the user. For example, some provider want their memberships to be reduced to half when transferred.

This is the part smart contracts solve.

[bawolff]

> To verify you have a HN account (membership) today, a service provider need to build something like keybase. That is complicated and will be different for each service.

What's wrong with plain old digital signatures in this contrived scenario. If for some reason this was desired, hn signs an assertion that so and so is a member. Person presents this assertion as neccesary. No blockchain required.

Memorizing hn's public key is no more hard than memorizing what their nft is.

I suppose you'll say transfering memberships. If hn is onboard with the transfer they could just issue a new signed assertion. So the only use case is if you want to transfer ownership against the service provider's will. But how does blockchain solve that? Unless i missed some great advance in zkp, all transfers are public on the blockchain, and service providers can trace the transfers and not recognize transfers they don't like.

> They can be transferred, expired, and change depending on the action of the user. For example, some provider want their memberships to be reduced to half when transferred.

What's a real world example of someone wanting something like this? I can't think of any.

[_3jh0]

> What's wrong with plain old digital signatures in this contrived scenario. If for some reason this was desired, hn signs an assertion that so and so is a member. Person presents this assertion as neccesary. No blockchain required.

Blockchain isn't required for this part and I answered why not certificates in this thread elsewhere. The simple reason is, wallet based authentication & authorization is more mainstream than pgp today. You also need to pay for memberships and that can be done through the same wallet. Arguably better UX.

> If hn is onboard with the transfer they could just issue a new signed assertion. So the only use case is if you want to transfer ownership against the service provider's will. But how does blockchain solve that?

Indeed. That's the point of storing membership data on blockchain. The user and community can go against the service provider. Think of freenode transfer a while ago, if the identity, moderation, ownership of channels, etc data was stored on the blockchain and controlled by the user. The community could migrate to another IRC service which fetched data from the blockchain and each user could get the same account they had on freenode by verifying they owned that data.

Check out other commenter on the same thread too. https://news.ycombinator.com/item?id=29862347

[WJW]

> more mainstream than pgp

This is the one of the most "damning with faint praise" comments I have seen this year.

[bawolff]

> The simple reason is, wallet based authentication & authorization is more mainstream than pgp today.

So what, the killer feature is its UI isn't as shit as the program world famous for having a shit UI

Besides if that is your metric, JWTs are definitely more mainstream than blockchain stuff.

>Think of freenode transfer a while ago, if the identity, moderation, ownership of channels, etc data was stored on the blockchain and controlled by the user. The community could migrate to another IRC service which fetched data from the blockchain and each user could get the same account they had on freenode by verifying they owned that data.

Kind of hard to have a secret cabal channel if membership is public. Does this mean to ban someone from a channel you need to pay a transaction fee? That sounds fun from a channel op perspective.

[csmpltn]

> "To verify you have a HN account (membership) today, a service provider need to build something like keybase. That is complicated and will be different for each service."

No, they need at-best a small subset of what OAuth offers. OAuth is already distributed in that sense. It's a standard protocol which accounts for this exact scenario. This is a solved problem today.

It's not different than "login with Google"/"login with Apple".

> "You need some way to pay for membership without a middleman. This is solved by cryptocurrency part of the blockchain these nfts are stored on."

What does this sentence even mean? Your membership costs are on a per-service basis, and they are tied to each service you want to pay for. Different services have different costs.

This could make some sense if services wanted to get paid with Bitcoin, but ironically enough - the Bitcoin must be converted to USD at some point down the chain?

> "Memberships are also more complicated than a list of email addresses. They can be transferred, expired, and change depending on the action of the user."

Sure, but wtf does the blockchain have anything to do with this? You're free to have an account with any service and manage it as you wish on an individual per-service basis.

[dragonwriter]

> I as a third party can verify whether someone has a valid HN membership and provide them perks based on their membership. That is the problem a distributed ledger solves.

It's the problem delegated auth (OAuth, etc.) already solved.

> You need some way to pay for membership without a middleman. This is solved by cryptocurrency part of the blockchain these nfts are stored on.

But... it's not, because a system that relies on a distributed network of middlemen isn't “without a middleman”.

> Memberships are also more complicated than a list of email addresses. They can be transferred, expired, and change depending on the action of the user. For example, some provider want their memberships to be reduced to half when transferred.

Smart contracts just add complication; this is trivially solved internally in centralized membership systems.

[fragmede]

Well, you don't need to sign up for yet another service for one. People don't want to have yet another email and password to remember. That's what OAuth and all that machinery was invented to solve.

AuthN is one of the few use cases where having a public shared database/blockchain and users authenticate using their private keys works out better in some respects because the alternative is to depend on a centralized user database owned by a private company (eg Facebook). What happens on all of the sites you used Facebook login on, if your Facebook account gets suspended?

[sdenton4]

So we sacrifice member privacy for the sake of spam? Who would want this other than the spammer?