akaprofiles (neilck)
AKA Profiles

https://www.akaprofiles.com

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

Public Key

npub1qqqqqqmh2spyzdv44j0pvy4765ygzh5ca392n452yc507c25s4hs4q93ze

NIP-57 Address

Profile Code

nprofile1qqsqqqqqqdm4gqjpxk26e8skz2ld2zypt6vwcj4f669zv28lv92g2mcpzdmhxue69uhhyetvv9ukzcnvv5hx7un8qy28wumn8ghj7un9d3shjtnyv9kh2uewd9hsdyrn7q

Publishing to

relayable.org

relay.damus.io

relay.nostr.band

Author Public Key

npub1qqqqqqmh2spyzdv44j0pvy4765ygzh5ca392n452yc507c25s4hs4q93ze

Show more details

Last Notes

2024-09-06 08:46:36

- 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 08:17:51

- 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-08-28 17:04:45

Testing out ditto.pub, posting using non-ditto NIP05 profile. Let's see if it appears in the ditto.pub feed.

2024-06-27 20:56:06

- 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-27 20:39:58

- reply

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.

2024-06-05 11:25:54

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

2024-06-05 10:21:34

- reply

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

2024-05-23 10:33:24

- reply

Let me know what you need.

2024-05-23 10:31:52

- reply

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.

2024-05-23 01:41:17

- reply

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

2024-05-08 19:51:47

- 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-05-08 19:22:13

- reply

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.

2024-04-04 22:24:49

- reply

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.

2024-04-01 18:31:40

- reply

First post.

2024-04-01 18:30:05

Good morning.

2024-03-27 17:43:36

- 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-18 13:04:58

- reply

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.

2024-03-17 10:40:35

- reply

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

2024-03-17 10:27:52

- reply

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

2024-03-17 09:31:10

- reply

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

2024-03-12 09:13:48

- reply

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.

2024-03-12 03:31:18

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 21:40:00

- 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 10:00:33

- reply

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

2023-09-29 02:39:34

- reply

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

2023-09-27 22:05:53

- reply

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

2023-09-27 20:46:56

- 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 20:38:01

- 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 20:40:01

test post