pull down to refresh

Howdy @lunin, thank you for sharing your project here. The best places to receive support form the bitcoin community are many, Stacke.News is one of them. However I also suggest you to try the following: https://geyser.fund you also have @steliosats and @metamik around here that are able to respond to any question you have. They also have their own dedicated support channels https://angor.io that is next P2P crowdfunding for startups There are also more platforms with a more traditional approach, either case, most of the projects are bitcoin-only. Another detail to consider, is that KYC is not really seen as a good thing around the bitcoin community, for those that understand the implications of doing such thing, stay probably away from such services. Evermore, nostr protocol has an embedded trust system, commonly known as Web of Trust, it does not require KYC and has been proven to be really useful for many use cases. Can you point us to resources that help better understand your project? How and why a sovereign individual would need identity verification? How are you planning to integrate bitcoin and lightning?
You're spot on about KYC. The traditional, centralised version just doesn't work for a lot of people in the Bitcoin ecosystem. That's why we're not building the usual KYC — we're creating a peer-to-peer, user-controlled identity protocol.
With Shegby and HumanRank, there's no central authority, and users don't have to disclose any data unless they want to — and only to the people they trust. Even then, they can decide exactly what to show and even make money from access to that data if they want to.
Basically, we're creating a KYC layer that's all about user privacy, decentralisation and freedom. It's more like "proof-of-personhood" than KYC as the industry knows it.
We think this is really important for getting more people to use Bitcoin in all sorts of situations where you need to prove who you are – but without losing the trustless and censorship-resistant nature of Bitcoin.
I'm happy to share more on how we're approaching this and how it aligns with Nostr's Web of Trust and Lightning-based payment flows. Thanks again for the warm welcome.
0 sats \ 2 replies \ @AG 1 Jun
I still not seeing it... Bitcoin does not need KYC, it works perfectly as it is. So, how you differentiate your protocol from nostr Web Of Trust (WoT)? Why add KYC on top of it? What's the need? What are the use cases are you covering? What's the problem to be solved?
reply
Thanks for your questions, by the way. So, to sum up: No, Bitcoin doesn't need KYC, but new social use cases built around Bitcoin like P2P services, borderless collaboration, Network States – often do. We're not enforcing KYC, we're enabling peer-verified personhood — decentralised, voluntary, private by default.
reply
Bitcoin doesn't need KYC. That's exactly why we're not trying to "add KYC on top of Bitcoin" - we're building a decentralised optional trust layer that can support use cases where personhood and accountability are needed, without sacrificing user sovereignty.
Our protocol, Shegby, was inspired by the real-world needs we had when building a P2P marketplace of services - where both buyers and providers need a way to verify trust with each other before entering into a transaction. When people are interacting with each other online, especially when it's across borders, there's a real need to check who they are and what their reputation is, while also keeping their privacy intact. That's the gap we're solving.
You might say our HumanRank system is like Web of Trust, but it's set up like PageRank:
  • One person who's been verified can verify another person.
  • The trust score decides the ranking of the verifiers.
  • It's up to the user to decide who to trust, what to reveal, and to whom.
At the end of the day, we're aiming to create a Network State (inspired by Balaji S.), where the flow of citizenship, collaboration and services between individuals needs to be voluntary but also strong identity models - not reliant on state-controlled systems.
reply