Agreed! For akaprofiles, I added additional tags to NIP-58 events to support adding data to badge awards (e.g. Twitter handle when issued a badge verifying pubkey owns this accont).
https://www.akaprofiles.com/docs/reference/nostr-events
My proof of concept is close to what you are asking, but not exactly the same.
If we replace Bob with AKA Profiles, and Alice wants to attest she lives in Germany she could go to:
https://get.akaprofiles.com/njump/naddr1qqt8wkrk29xk7ujztpqnwu62we5xk53kfq656dgzyrkm4aaey4raej2rn90ufkevka7d0g3vxj25z7dfnnqvp59vhnrq2qcyqqq82wgt5ph68
Based on her IP address, AKA Profiles would award Alice a GEO Location badge with her current Country, Region, and City.
Any app / person then who trusts AKA Profiles as an issuer, could verify Alice has been awarded a GEO Location badge with country: Germany.
For P2P attestation of any event, there would need to be an "attestation" kind, where the event pubkey is attesting that events referenced in the e tags are true.
When it comes to belief and trust, generally trusted authorities are efficient, but create centralization. Web of trust solutions with no barriers to participation are decentralized but are susceptible to tampering or collusion. I think for Nostr there should be a machinist where a person earns trust with their locally community authorities (like mods) that then becomes verifiable and this transferable to other communities.
AKAProfiles extends NIP58 events to support adding data to badge awards. (see https://www.akaprofiles.com/docs/reference/nostr-events) To support private data, I would add "private" as an option on the "field" tag added to the Badge Definition Event. On the badge award event, for private fields, instead of returning the private value using the "data" tag, I'd return a URL/URI which can fetch the data, being agnostic in how URL authorization is performed.
I believe that any data a user isn't comfortable with being widely published should never be published to relays, unless decryption requires their own private key, as the risk of accidental disclosure due to a key comprise is too high.
Kind 0 is hard, because its a replaceable event. Every single client has to implement Kind 0 correctly, otherwise data is lost when a client publishes the event with only the data it cares about. I think badges are better, and the data is seperated into different events signed by the issuer who is "attesting" the information is true.
Just a thought about replaceable events. Overwrites of metadata or follower lists by clients who don't include the data from previous events causes users headaches.
What if a new replaceable event includes the current event's id as a tag? It proves the publishing client was at least aware of the previous event.
Client could choose to ignore the latest replaceable event if the tag doesn't exist, and fall back to either its own cached values or the last replaceable event with that has this tag. #nip01
Sorry for the delayed response @manime. I've been heads down coding.
Currently the akaprofiles browser extension, is a simple Nostr Signing Extension that supports multiple nostr keys.
akaprofiles.com is an automated Nostr badge issuing service.
The two projects are not yet connected, but likely will be in the future, where the signing extension acts as the wallet for not just the user's keypairs, but also their badges.
Originally I tried to treat Nostr events as my app's database. Now, I only add tags (or would proose a new NIP) if that data needs to be shared with other apps.
The theory of disruptive innovation (https://hbr.org/2015/12/what-is-disruptive-innovation) supports your position: "Disruptive innovations don’t catch on with mainstream customers until quality catches up to their standards"..
However, Nostr developers, myself included, may not prioritize fixing features in common with existing social media apps because implementing novel features is more rewarding as a creative pursuit. Nobody is getting paid to improve "boring" features to reduce churn.
Personally, I'd much rather see Nostr clients continuing to evolve in weird and wacky ways, creating differentiation, before the focus on stability of features that already exist. It's like the early days of smartphones, before everything became a iPhone clone.
I'd be willing to take off my developer hat and put back on my product management hat, to help find and coordinate projects with high level goals in common.
What if the hashed phone number is stored as an event signed with a unqiue private key? That private key is stored on the user's behaf by the app which published the event. The app or service that finds matching phone number hashes then publishes a connect request event to the phone numbers public key, signed using the requesting user's private key. The phone number user can then see the connection request, and choose to accept or deny.
I've been thinking about building the general use case for this in AKA Profiles, where badges are always published using a unique private key, allowing badges to be discoverable, but not directly attributable to a user's public key without their permission.
I found gemini.google.com does a better job than ChatGPT 3.5 in handling questions about structured data. You can ask it to write the code to answer your questions, so you can double check it's logic. If you ask it to execute the code, it says its not allowed, but if you ask it to "pretend to execute the code" it will give you the output. lol.
@hodlbod 's invite link for coracle.social has merit, where the invitation link contains a recommended list of people to follow. Other clients could do the same thing. It shifts the "king making" from the client to the individuals who are bringing their people into Nostr, who should know their interests better anyways.
As far as I understand it, Coracle has Invite Links, which includes the claims to authorize access to Triflector relays / groups in the link. If the link parsing oce and the "joinRelay", "publishGroupEntryRequest", etc. functions in Coracle that publish the Nostr events with claims were abstracted into an SDK, that would enable any web2 HTML webpages to grant authorization based on claims without the developer needing to write a native integration from scratch.
I've been thinking about how I can integrate https://github.com/neilck/nostr-badges with this invite scheme, to automate the registration / enrollment part of the user flow.
I'm current working on this, and published a nostr-access-control library (https://github.com/neilck/nostr-access-control) as a proof of concept.
As I work through the front-end app through, that library will probably change.
1. When applying for a group membership badge, a user must have all the required admission badges, including a "not-a-bot badge" issued by an web app running Captcha.
2 When using a Nostr app, app can promote notes and other content from people who share the same membership badges.
We fight spam by promoting the relevant content versus trying to surpress the negative content.
https://m.primal.net/HMGF.png
All within your client (no new NIPS / relay support needed)
1. From a post, have option to set "summaries only in feed" option for the follow..
2. In "Feed" when a new note is found for respective person, display a summary message of posts and tags (see image mockup above for a summary of your mom's posts)
3. When use clicks "View now", all their posts since the last date you viewed "View now" are shown.
4. Update last View Now date for this follow.
I think this covers most of your use cases.
Forgot to add, clicking the # tag in the summary, only shows you their posts with that tag. I assume their are tags associated with product vs content posts, so you can view only the recommended product posts.
https://m.primal.net/HMGF.png
All within your client (no new NIPS / relay support needed)
1. From a post, have option to set "summaries only in feed" option for the follow..
2. In "Feed" when a new note is found for respective person, display a summary message of posts and tags (see image mockup above for a summary of your mom's posts)
3. When use clicks "View now", all their posts since the last date you viewed "View now" are shown.
4. Update last View Now date for this follow.
I think this covers most of your use cases.
Oddbean new post about login | logout
Notes by neilck | export