My extension supports multiple key pairs but is out of date. https://chromewebstore.google.com/detail/aka-profiles/ncmflpbbagcnakkolfpcpogheckolnad?hl=en&pli=1

It’s open source

https://github.com/neilck/aka-extension


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.


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.


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


neilck

Founder of www.akaprofiles.com
Repos: https://github.com/neilck


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.


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.


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


First decentalized identity platform with a chance to reach mass adoption.


Let me know what you need.


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.


I was looking at implementing NIP-03 before.  Did you need someone to test your experiment?


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.


First post.


Good morning.


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.


Verified subscriber to Itch Boots Youtube Channel.


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.


If you have a clear idea of the users you are building for, that works.


@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.


What would this ideally look like?
Just planning my roadmap now for the "content creator" features of www.akaprofiles.com.


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.


Version 0.2.0 of AKA Profiles released!
Micro-service to automatically issue Nostr badges.

Live: https://app.akaprofiles.com
Repo: https://github.com/neilck/nostr-badges
Docs: https://www.akaprofiles.com

https://image.nostr.build/2bbbba7a488d694a5c4a478389e9b22b01c9300041adf9c6e52068f61be4a035.png
https://image.nostr.build/c0a7f8d5f8c5c0460e003f2e7612bbb9a131def0713e5fc70e182431911a4bcf.png

#nostr


Dedicated to advancing scientific knowledge through the chasing of extreme weather.


User has verified their location based on IP address


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.


I haven't thought about it like that...
until now. :P


Regarding invite codes, I've proposed using Nostr badges for access control.
https://github.com/neilck/nostr-access-control


I found it hilarious you used your mom in the use case, so had to follow suit!


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.


This is a sample exclusive resource created using nac-demo-app


This is a sample badge created using nac-demo-app


Does anyone have sample code of single instance NDK instantiation in a React app (client side)? I assume it would be using Context API...