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.
It’s the closest NIP (NIP-58) for attestations, where an issuer attests something is true about a recipient.
I’m glad you like it. I don’t get much direct feedback, so thanks.
I think it's agreat idea, just haven't run into a use case for it yet. nostr:nprofile1qydhwumn8ghj7mn0wd68ytnrda5kuen4dejxjapwvdhk6tcpz3mhxue69uhhyetvv9ukzcnvv5hx7un89uq3vamnwvaz7tmjv4kxz7fwd4hhxarj9ec82c30qywhwumn8ghj7mn0wd68ytfsxgh8jcttd95x7mnwv5hxxmmd9uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcqyqqqqqqrwa2qysf4jkkfu9sjhm2s3q27nrky42wk3gnz3lmp2jzk7rsam5q has prototyped some stuff.
Yup. Decentralized ID systems have failed in the past because credentials are not easily discoverable. Pseodonymity and multiple profiles is the way to go.
This. With two paid features:
1. See events up to 1 year old.
2. Make my events available to everyone forever.
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:
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).
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.
First decentalized identity platform with a chance to reach mass adoption.
nostr:npub1qqqqqqmh2spyzdv44j0pvy4765ygzh5ca392n452yc507c25s4hs4q93ze is this a new browser extension?
akaprofiles.com
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 think there's been an inflection point recently in NIPs that are being proposed. Some examples:
- Products with pubkeys: https://github.com/nostr-protocol/nips/pull/1225
- Shared-ownership events: https://github.com/nostr-protocol/nips/pull/1192 and https://github.com/nostr-protocol/nips/pull/1015
- Spreadsheets: https://github.com/nostr-protocol/nips/pull/1189
- Relational databases: https://github.com/nostr-protocol/nips/pull/1168
- Relay-specific notes: https://github.com/nostr-protocol/nips/pull/1146
- Editable notes: https://github.com/nostr-protocol/nips/pull/1090
- Restricted events: https://github.com/nostr-protocol/nips/pull/1083
- Relay-based access control: https://github.com/nostr-protocol/nips/pull/1030
- Protected events: https://github.com/nostr-protocol/nips/pull/1029
- Closed groups: https://github.com/nostr-protocol/nips/pull/875
Some of these I like, some I don't. But most of them go beyond adding new features to nostr (for example audio, video, speedruns, resumes, etc), and begin to change how nostr actually works.
Nostr can be an everything app, but I think that means something very specific. Nostr can represent data types from pretty much any domain, but it can't actually support all the semantics needed to build any arbitrary system.
I would suggest conservatism in what we build on nostr, but of course anyone can build whatever they want. But I do think it's possible to identify things that nostr is good at, and things it's bad at, and play to nostr's strengths.
Nostr's strengths:
- Being able to model any data type orthogonally to the rest
- Single-owner, self-authenticating, atomic data types
- Potential for robust content dispersal and retrieval if we can flesh out NIP 65 etc.
Nostr's weaknesses:
- Mutable state, non-atomic state
- Shared ownership, key delegation/rotation
- Privacy — metadata will always leak, lack of consistency makes key rotation harder
- Consistency — not everyone has the same view of the world
- Transactionality — nostr isn't good for updating multiple pieces of data in lockstep
It happens that the original use case of nostr — public broadcast social media — benefits greatly from nostr's strengths, and isn't bothered by any of nostr's weaknesses. Blob storage like what blossom is building also works well in this paradigm. A lot of the use cases @PABLOF7z has identified work beautifully well because of the single-owner public-read nature of nostr, which makes forks easy to model.
But things like access control, relational data, collaborative document creation, heavier datasets, or anything that requires a solution to the double-spend problem become very awkward (or impossible) to model on pure nostr. A simple example of this is lists. Not only is it common for a single user to mess up his follow lists because of a lack of consistency between clients or devices, but commonly requested features like shared ownership lists immediately result in a huge increase of complexity, either on the key management side or on the data structure side. Both of these problems are difficult to solve on nostr due to lack of consistency — keys can't always be reliably or safely shared, and linked data structures spanning multiple events by different authors can be hard to assemble reliably.
I think the danger here is that if we as a developer community fail to realize the limitations of nostr and try to adapt the protocol to fit every possible use case, on an ad-hoc basis, we're going to end up with a tragedy of the commons, where no developer can comprehend what must be done to get his work done, and all kinds of weird artifacts appear for end users that no one can explain.
Here are some suggestions I have for preventing this from happening. I realize no one is going to follow them. But maybe they can be helpful for avoidance of wasted time.
- Don't overload event kinds. Many people (including myself) have tried to extend kind 0 with attributes for forms, products, and groups, but that leads to madness. Instead, create a new metadata event signifying a different kind of agent.
- Don't model things as replaceable events if you can avoid it. This creates the problem of shared mutable state, which nostr doesn't have a good story for resolving. They also have a hard limit on how big they can be.
- Use different keys for different things. For domains where some kind of access control needs to be implemented, not tying everything to your main pubkey makes it possible to create and burn keys as needed. Incidentally, this can help users maintain better privacy. An example of this is private groups, which have a dedicated key separate from the group creator's own key.
- Event ownership should always be (is) single-key. If you need shared ownership, figure out a way to share keys. More work needs to go into key invalidation and rotation for this to really work.
- Explore the fork model — this is "my" version of the same thing, and coexists with rather than supersedes the original. This has potential not just for groups or wiki entries.
- Distinguish between different ways to use relays. Relays may be used as indexers (holding specific event types or supporting different features like search/count), repositories (holding many diverse events, to be used with filters), or curated feeds (to be used without filters, or with only a few filters).
These are just suggestions, and many of them may be wrong. Nostr development is hard, and getting harder. Keep it simple.
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.
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.
What would this ideally look like?
Just planning my roadmap now for the "content creator" features of www.akaprofiles.com.
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
#nostr
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
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.
I think we need different types of "follow". What about something like this:
1. Friend — this person doesn't show up in my feed. But I like them, and want to keep track of them, and maybe be reminded of them on occasion (hey hodlbod, here's what your friend X has been up to this summer). I trust them, and want to factor their opinions in to content recommendations generated for me.
2. Follow — I want to know what this person says if it has engagement, is popular, or matches some other filter, like topics I've expressed interest in. The Hacker News bot might fit in this category.
3. Super Follow — I want to see everything this person says. These are the people on my "pure signal" list currently.
4. Subscribe — these are people you don't care about, and whose opinions you don't care about per se, but are people who get paid (either by you or by advertisers) to recommend content or products. Could be bots or influencers. You'd never see their content, but you would see things recommended by them.
Items #2 and #3 are variants of the same thing, and could be conflated by assigning a decimal value to your follow (suggested by nostr:nprofile1qqsfcts2suzpxaeuhy2mnjwd9cwt69l98t3tp2r2hf09hu8uz0zzp5spzfmhxue69uhhqatjwpkx2urpvuhx2ucpz3mhxue69uhhyetvv9ujuerpd46hxtnfduq3vamnwvaz7tmjv4kxz7fwdehhxarj9e3xzmnyuurtjm earlier, but I used to have something like this in Coracle).
The first category is entirely different though, because the value of the relationship is not based on what they say, but who they are. I honestly don't want to see anything my mom posts to social media unless she tags me in it (in which case she'll email me). But she's one of the most important people in my life.
Likewise the final category. This is an entirely transactional-type relationship, and is exploited to provide additional social signal to otherwise neutral content.
So, any other categories? This is really quite similar to nostr:nprofile1qqsyvrp9u6p0mfur9dfdru3d853tx9mdjuhkphxuxgfwmryja7zsvhqpr4mhxue69uhkummnw3ez6ur4vgh8wetvd3hhyer9wghxuet5qyt8wumn8ghj7anfw3hhytnwdaehgu339e3k7mgpzpmhxue69uhkummnw3ezuamfdejsxp7af9 's "relationship status" nip, but with more ability to quantify what clients can do based on the relationship. It could also be implemented (of course) using NIP 32.
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.