nips VS did-core

I'm interested in this too. While I note the [slightly chaotic] plethora of NIPs[0], and many of them look blockchainy, NIP-01 is looks ultra pragmatic and simple, and is the only one that is required to be implemented, AFAIK.

  [0] https://github.com/nostr-protocol/nips

For you and others following. Common in early nostr apps. The web-extension spec is defined in https://github.com/nostr-protocol/nips/blob/master/07.md. Most apps check for window.nostr, then fail silently when it's missing or blocked. There are also some popular extensions in that list.

https://github.com/nostr-protocol/nips/blob/master/65.md

The TLDR is that when a Nostr client supports NIP-65, it broadcasts to all known relays (which is continually updated/expanded) the list of relays that User A posts their stuff to.

This means that as long as User B is connected to at least one of those "all known relays", their client now knows what relays User A posts their stuff to, and will specifically fetch things from those relays when it needs to load User A's things.

It's essentially the Nostr take on the Gossip protocol: https://en.wikipedia.org/wiki/Gossip_protocol

I think your best bet here is Nostr (Notes and Other Stuff Transmitted by Relays): https://nostr.com https://github.com/nostr-protocol/nostr

Nostr isn't a federated platform like Mastodon or Lemmy, it's more similar to the AT protocol created by Bluesky, whilst being far simpler to understand and write apps using it. The nostr protocol is defined by a series of NIPs (Nostr implementation possibilites https://github.com/nostr-protocol/nips), the most basic of which can be implemented in a client or a relay in 50-100 lines of code in any modern programming language.

Each user runs a client, anyone can write a relay or run any of hundreds of existing implementations, both clients and relays can choose to support a number of NIPs. Users have a public-private keypair, and distribute notes to relays signed with their private key, which are verified by relays. Clients subscribe via websockets to any number of relays (I usually have 20-30), and receive notes from all users on those relays' databases, or filtered by the public keys of the users you're following. Relays for the most part don't communicate with each other. If you're ever blocked or banned from a relay, you'll still be able to have your notes seen as long as you have at least one relay in common with anyone who wants to see them. I run my own as well for extra resiliency.

At the moment there's ~50 standardised NIPs, which add features like likes, zaps (bitcoin tips for notes), user status, post expiration, mentions, search, DMs, and public chats. Nearly all of these are supported by popular clients and relays. While nostr is primarily used for social media at the moment, it's already possible to build upon as a protocol for pretty much any online service.

The total active user count on most public relays I'd estimate is somewhere around 500k to a million, though the nature of the protocol makes it impossible to estimate its true size. The perceived community on most relays before following anyone frankly can get pretty cancerous, mainly due to a lot of clients sorting notes by new by default, so I can only hope to high heaven it'll improve as it grows.

Though like any new non-centralised platform, it's more difficult to get started on for most non-technical users as they have to pick one of hundreds of clients to install, and requires caution to never leak your private key and be very wary of which clients you trust it with.

There is no "zaps balance". Zaps are just receipts of lightning payments.

The basic idea is that a lightning node will detect when the invoice with a nostr note inside is paid, and then send the receipt to nostr as a nostr note, with the original bolt11 invoice inside with the signature from the user who sent the zap.

It's all describe by NIP-57, a spec I put together to support this:

https://github.com/nostr-protocol/nips/blob/master/57.md

I was working on c-lightning at the time and I thought it would be really cool to replace the "like" button with an instant bitcoin micro-payment. I think it worked out quite well! There are many sites utilizing zaps in all aspects of the protocol, such as a decentralized market for AI job requests (data vending machines), zapgoals and zap fundraisers. All built on this note type. protocol synergy!

Take a look at NIP-23: Long-form Content https://github.com/nostr-protocol/nips/blob/master/23.md .

In 1994, Tim Berners Lee, the creator of the World Wide Web, founded the World Wide Web Consortium (W3C). The W3C is made up of groups of people focused on setting the best practices and standards for building the web. For example, the W3C develops and maintains standards for HTML, CSS, Web Accessibility, and Web Security. In July 2022, The W3C officially published standards for Decentralized Identifiers. This way, technologists would have blueprint for building and managing digital identity as we make the shift towards controlling your identity on the internet. Check out the Decentralized Identifiers specification here.

A few months ago, I started looking into decentralization on the web and how this could impact our world as we know it today - thanks to Web5 and our work at TBD. One of the biggest and most important pillars in achieving this decentralized future is called Decentralized Identifiers (DIDs).

Unfortunate choice of name, given https://www.w3.org/TR/did-core/.

I'm also a software engineer, and I'm actively working on making it a thing in a parallel system (referenced above) lol. DIDs have been a standard for a while, and as someone who's had my SIN compromised (by Equifax of all places), our current way of handling ID is far easier to hack than a well implemented digital ID would be. Its actually asinine to me that I was compromised in 2016, and DID existed then... yet here we are 7 years later, with identity thefts only climbing year-over-year, and we still have antiquated, and clearly failing identity systems in place.

DESCRIPTION: We are looking for a Rust developer to join the team developing a cross-platform digital identity application using the Tauri framework and several (cloud-based) Rust components for Identity-as-a-Service solutions. We are a young start-up that is developing digital identity products and solutions for people and organizations, based on the decentralized identity standards. Our work includes developing open-source implementations of standards such as DID and Verifiable Credentials from W3C and OpenID4VC from the OpenID Foundation. Using this technology, people gain control over their own digital identities and data and can easily share verifiable information with third parties, enabling more privacy and digital trust.

DID methods are the W3C solution to decentralized identity: https://www.w3.org/TR/did-core/

https://www.w3.org/TR/did-core/#key-and-signature-expiration

"9.8 Verification Method Revocation" https://www.w3.org/TR/did-core/#verification-method-revocati...

Blockerts is built upon W3C DID and W3C Verified Credentials, W3C Linked Data Signatures, and Merkel trees (and JSON-LD). From the Blockerts FAQ

What do you think about Decentralized Identity (DIDs - https://www.w3.org/TR/did-core/)? With it, you can have several identities and easily generate new ones when needed (but you probably need to have a single, government-recognized identity for the real world).

Europe seems to be working hard on establishing an identity for every citizen: https://commission.europa.eu/strategy-and-policy/priorities-... (most countries already have that, but this is about unifying the various countries' ID systems).

Domain names as handles are a cool idea, and you can already do a variant of them in the "fediverse" either by hosting your own instance of a service or by configuring a WebFinger alias (which is what I do).

I'm less convinced by DIDs[1], which is what Bluesky seems to run on: I've yet to see an explanation for why the DID standard exists, given that it effectively punts all semantics (including basic things like cryptographic verification) onto unstandardized "methods" in an uncontrolled global namespace.

[1]: https://www.w3.org/TR/did-core/

- very close is the foundation regarding Decentralized Identifiers by the W3C https://www.w3.org/TR/did-core/ // https://w3c.github.io/did-core/