neilck
AKA Profiles

Nostr is a counter-culture reaction to the dominant social media apps. Like the 60s, its about freedom of expression and taking back the power, but expressed through technology instead of music and fashion.

2025-03-20 15:19:15 UTC

- reply

It’s the closest NIP (NIP-58) for attestations, where an issuer attests something is true about a recipient.

2025-03-20 15:16:44 UTC

- reply

I’m glad you like it. I don’t get much direct feedback, so thanks.

2025-03-19 06:44:29 UTC

- reply

Yup. Decentralized ID systems have failed in the past because credentials are not easily discoverable. Pseodonymity and multiple profiles is the way to go.

2024-11-27 21:19:41 UTC

- reply

This. With two paid features:
1. See events up to 1 year old.
2. Make my events available to everyone forever.

2024-09-11 14:31:15 UTC

- reply

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.

2024-09-06 06:46:36 UTC

- reply

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.

2024-09-04 06:17:51 UTC

- reply

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

2024-06-27 18:56:06 UTC

- reply

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.

2024-06-05 08:21:34 UTC

- reply

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

2024-05-23 08:33:24 UTC

- reply

Let me know what you need.

2024-05-22 23:41:17 UTC

- reply

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

2024-05-08 17:51:47 UTC

- reply

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.

2024-03-27 16:43:36 UTC

- reply

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.

2024-03-17 09:40:35 UTC

- reply

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

2024-03-17 08:31:10 UTC

- reply

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

2024-03-12 02:31:18 UTC

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

2023-10-17 19:40:00 UTC

- reply

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.

2023-09-29 00:39:34 UTC

- reply

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

2023-09-27 18:46:56 UTC

- reply

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.

2023-09-27 18:38:01 UTC

- reply

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.

2023-05-13 18:40:01 UTC

test post