China doesn’t respect American patent laws. So I guess you’re right lol. What’s even the point
I am building a letterboxd app as well, but I am using NIP-32 for the review. I think that is the correct NIP for something like this. Any reason you haven’t done that?
Social media should be a place of action. The UX should discourage static identities and encourage dynamic action.
Result: more cohesion, less quibbling, shared values expressed organically cc nostr:npub1mlcas7pe55hrnlaxd7trz0u3kzrnf49vekwwe3ca0r7za2n3jcaqhz8jpa nostr:note1kcxkecrkdurcw0vghekten0mx5v4jkgjjz039x89fwh6cmfda8eqmka80e
Social media should focus less on your “brand” (which is static) and more on your actions.
When setting up an account, prompt user:
- what have you done
- what are you doing
- what are you going to do
This tells you so much more than a “bio”
If grabbing that data isn’t supported at the top level of the library (NDK or something like Noswhere), i thought it would be very inefficient. Maybe it’ll work ok though!
We need to definitely split multiple references into multiple ‘r’ tags though. Otherwise we won’t be able to say “grab all posts with this reference” if that reference is in the 3rd spot.
With both NDK and the newish relay search filters not supporting more than two items in a tag array, the underscore “l” tag in NIP-32 will have issues. Especially since the “quality” rating is the 4th item in the array and that value will need quick access for aggregation
Sounds like it’s best to just have multiple r tags for the same post then. Maybe like
[“r”, websiteURL],
[“r”, plainTextName],
The idea with the plain text format is to allow references to slowly become more “NOSTR native” over time. Use external databases as a crutch, until it’s not needed.
Maybe that is what a consistently formatted hashtag (“t” tag) is for though. Not sure
If we need to add more data to a reference (say it exists in two databases and we want to include both IDs for robustness), do you recommend we have an “r” tag for each reference of the same thing?
Will the tag searching assume that each tag will only contain 2 values? The tag type and the value? Or would the noswhere search work with a tag like this as well:
[“r”, “url”, “title”, “id”]
?
nostr:npub1zuuajd7u3sx8xu92yav9jwxpr839cs0kc3q6t56vd5u9q033xmhsk6c2uc question about NDK filters:
Do the filters assume that each tag will only contain 2 values? The tag letter and the value? Or would the NDK filters work with a tag like this:
[“r”, “url”, “title”, “id”]
?
The hard part is incentivizing the maintenance and upkeep of multiple different open networks.
An admin needs to run a nostr node, a simplex node, and some other node? All on different networks with their own costs involved.
Or an admin can just run a nostr node and let it be a generic dumb pipe for everything, incentivized with just one economy instead of 3+ nostr:note1x55nr2um7jgykkh5qle3jazjm0s5helcjqcl5dqqsadhgxj7syfs9pcg26
Nostr can very well be the base layer for multiple different protocols. It’s very generic. Heck, someone is even building cyberspace on nostr.
The extension won’t let me add a nostr key without giving you my email. Maybe that is an error?
What is nprofile? I just saw it in the Gossip Github repo. Why would someone want an nprofile instead of just giving an npub?
Recommending an extension that uses your normal email is akin to saying Nostr requires KYC
Similar to Bitcoin, in these early days of Nostr, people will assume that it is safer and more private than it is.
Focusing on user protections and best practices will be key. The majority of users won’t want their posts to be public by default when they find out the hard way the risk that entails.
Once your note is signed, the world has hard proof that it’s yours and you have ZERO control after you send that to a relay.
Compare to Mastodon which is much more focused on users. nostr:note1wch5lq4knd0g6jcddax6jxj6za6z8xqc8j4pky6nl0tajajsqj6sk4053w
They said they’re happy with Mastodon but they do understand the drawback of accounts being tied to individual servers. So they’re willing to find something better for that reason