I'd guess at least nostr:nprofile1qqs0dqlgwq6l0t20gnstnr8mm9fhu9j9t2fv6wxwl3xtx8dh24l4auspzemhxue69uhkzat5dqhxummnw3erztnrdakj7qg4waehxw309a4x2mrv09nxjumg9ekxzmny9u7u83rc (vertex) and nostr:nprofile1qqsw2feday2t6vqh2hzrnwywd9v6g0yayejgx8cf83g7n3ue594pqtcpzemhxue69uhkgctkd9jzumn0wd68yvfwvdhk6qg4waehxw309ajkgetw9ehx7um5wghxcctwvsrwlzv5 (grapevine)
Discussion
I've tried neo4j and memgraph, both too slow for the speed I wanted to reach.
So I ended up building my own graph representation on top of Redis. Easier than it sounds
So I should pick your brain. I'm wanting to develop a sort of nostr based "phone book". The ux I want is like a user would for example choose a topic, like permaculture. That would present them with a big bubble containing all the topics within permaculture as smaller bubbles, within each of those bubbles is npubs who have those skills, ie biochar, Silvio pasture, etc.
Ways I'm considering linking an npub to a skill or attribute:
Hard coded - Jim = Biochar, etc in some repo
Bio - user defined hastags in their bio
Badge based endorsements - ie nostr:nprofile1qqsy6q3ua80awknlxp6m368qssqghct6ra6scca4meepumhcswkuwegppemhxue69uhkummn9ekx7mp0qyghwumn8ghj7mn0wd68ytnhd9hx2tcpzamhxue69uhkummnw3ezumn0dahx2uewvdhk6tc8vdatl could grant badges to people on certain topics, or perhaps badges containing "skill". maybe wot could be applied here, like for permaculture and mining I select xyz npubs as the endorsers I trust but for home repair I select another set of npubs. Only downside I see to this is badges seem essentially broken.
List based endorsements - using lists or follow packs
Other?
One thing I guess I would have to hard code somewhere is the nested categories (ie agriculture > permaculture > biochar)
Also the more I think about this is that it's more of a nostr based linkedIn than a phone book.
It depends what you want to achieve in specific. The problem of categorisation of skills is itself non perfectly solvable, so you should pick heuristics.
These heuristics would inform your nostr design, which would inform your db design. It really is a problem that can have many many different working solutions, it all stems from the assumptions.
For example:
- who makes the categories? You or the users?
- who attributes skills?
- skills are always positive or can be negative (e.g. bad speaker)
I think for categories, I would create them to start, I think that's needed just to get off the ground.
Skill attribution should be whoever, but probably be relay based badges or lists for the sake of initial bootstrap, but again I'm unsure if badges are actually currently working on nostr BC no badges show on nostr:nprofile1qqs24yz8xftq8kkdf7q5yzf4v7tn2ek78v0zp2y427mj3sa7f34ggjcpzamhxue69uhhv6t5daezumn0wd68yvfwvdhk6tcpzpmhxue69uhkummnw3ezumt0d5hszrnhwden5te0dehhxtnvdakz769wywf for me even though I've accepted several. I like badges over list BC of the accepting part vs someone can put you on a list you don't want to be on (ie I know SQL but don't want anyone to come talk to me about it). Which then makes skills always positive and wot would be what solves the negative part. Permies.com does this with their PEP badges which I've been thinking I should port to nostr since I first got on. Also i know it's not possible today, but something I could see myself adding to the badges spec would be multiple user signed badges (ie badge is only awarded if a and b sign notes granting it.)
So I guess what I would ask you is, have you considered badges as a booster to wot? Because really that would be the purpose of this, to add filtering layers to wot.
For example, imagine AWS and azure were on nostr. Their certs could be badges. As an employer, I could delegate my trust to those npubs, and use this tool to search for people they've granted badges to in specific areas.
Also, I guess badges could be used in any nostr app related to "knowledge".
I forget the nostr based wiki, but I could follow you and want to read wikis you've contributed to or vouched for on tech, but I don't necessarily care what you think about nutrition, for example.
These are fair takes.
No, I haven't considered badges yet in my WoT because few people use them (relatively to follow lists), so the "signal" I could extract would be little to none.
There must be a good UX and incentives for people to assign/check badges for this data to grow in importance. As an advice, I think you should focus on these aspects, meaning UX and incentives.
Why would someone issue a badge/certificate of skill on Nostr? How they have been doing it before? What problems do they have?
Badge UX would be important for sure, so I'll consider that. Assume it's amazing tho BC a lot of the questions I have are irrelevant.
Why nostr - I guess the only response to this would be the uncensorable nature of nostr. I don't care if my front end dev is a nazi, just make pretty stuff.
Prior methods and problems -
linkedin , endorsements are often given to colleagues as a kindness, because hey you added some to my profile I'll go add some to yours. Also nostr would basically enable you as a freelance person to rack up endorsements from clients. Would also allow you as a business to not have to maintain a list of good people to use for specific tasks. Imagine John comes and does good plumbing at your house. You then endorse him for sink work, so next time you need a plumber, you have your go to guy and you don't have to find his card and your endorsement helps other people.
I feel like developing this type of tool for one specific use case is the wrong approach. BC if done correctly, it almost could have the benefits of LinkedIn, angies list, uber, yelp, etc All at the same time. Badges are basically a way to attach a review to an npub for something they did. Which makes me circle back to, I wonder if there is a way to view badges someone has been given that the haven't accepted (ie uber driver gladly recieves all of the 5star badges but declines all the 1 star ones.) So I think it's possible that badges would be insufficient and lists don't even seem like the right data structure to solve the general case.
I think reviews are great when what's being reviewed is a product or service. Giving stars to people feels off from the human UX perspective.
There are multiple nip PRs for review, none seems to be achieving "convergence". To become a standard one needs a product that actually is used, so others will follow.
That's why I'm emphasising the UX aspect
Who makes the categories? Excellent question. Ok for you as dev to make them for starters, but the only answer that will work in the long run is that your WoT needs to manage the categories.
Which is why I authored this Decentralized Lists custom NIP:
nostr:naddr1qvzqqqr4gupzpef89h53f0fsza2ugwdc3e54nfpun5nxfqclpy79r6w8nxsk5yp0qyt8wumn8ghj7etyv4hzumn0wd68ytnvv9hxgtcprpmhxue69uhkv6tvw3jhytnwdaehgu3wwa5kuef0qqc8xetjwe5kxefdwpex7anfv3jhyuedvehhyttsv4e8xmmwv9kxj7n9vskhgun4wd6z6mt9w3exjcmn6a2pm6
Brainstorm currently uses #neo4j to track a graph with NostrUser nodes and follows, mutes, and reports as relationship types. This schema will gradually become more complex (add NostrRelay nodes, NostrEvent nodes, various other relationship types), and in its final form it will be a continuously-updating, personalized nostr knowledge graph that your WoT helps you to manage. Native graph databases with sophisticated query languages like cypher are designed for exactly this sort of thing.
I recently joined nostr:npub1healthsx3swcgtknff7zwpg8aj2q7h49zecul5rz490f6z2zp59qnfvp8p and we are putting the finishing touches on plans for a WoT Hackathon. We’re looking to support anything that’s open source that advances nostr towards a healthy ecosystem of personalized trust metrics that are calculated by service providers (which you can do yourself, or pay a third party) and then made available to clients. Graph database nostr relays will be very useful for this, and we’d love to see multiple implementations. So if you’re interested in contributing to one, consider doing it as part of the WoTathon. We’ll be thinking of how we can facilitate individuals with common interests finding each other to form teams for projects like this.
nostr:npub10mtatsat7ph6rsq0w8u8npt8d86x4jfr2nqjnvld2439q6f8ugqq0x27hf is also building a neo4j nostr relay and you should follow his work.
nostr:npub1mgvwnpsqgrem7jfcwm7pdvdfz2h95mm04r23t8pau2uzxwsdnpgs0gpdjc has used neo4j for DVMDash — Dustin are you still working with neo4j?
nostr:npub1057d3g2zw9w4ns8fq43yka3per9s2z9zmp4ryncgqqvv6e42tjrqnrxgd7 has worked with GUN, another graph database, and has expressed interest in making a GUN nostr relay.
Anyone else working on or interested in using graph databases within nostr?
#wotathon
So I ended up dropping Neo4j because DVMs should move to encrypted setups with NIP17 or NIP-EE, and I was using Neo4j for a global event debugger for DVM flows (which isn’t possible if everything’s encrypted).
But you can check out the representation I made and the code to insert and query Nostr data, could be helpful if you’re deciding how to structure Nostr data into graphs.
The main challenge as I see it is to ingest a high volume of events in real time. I’d love to see a general purpose nostr graph db relay, although I don’t think it will ever be as performant as non-graph relays for routine relay functionality.
Did you ever have any difficulties with real time data ingestion? Could you process them one at a time or did you need to batch them together at regular intervals? Or perhaps there was never a high enough volume of DVMs for this to be an issue?
Dude. Yes. Had to batch them basically. I was running on the low end of hardware, maybe just 1gb of ram, which is stupid expensive if you use the aura hosted version. Probably only worth it if you host Neo4j yourself on better hardware. I ended up doing a hybrid Postgres + Neo4j setup, so that I only needed to use Neo4j for queries that could benefit from the graph structure
What do you think of a hybrid solution? Last weekend I researched a few graphs to use. I settled on Cozo + sqlite. I think it solves the overhead you described. There's no need for batching. I vibed this once I picked what I thought was the optimal solution.
Cool. How big of a social graph have you achieved with it? I sync with wss://WoT.grapevine.network whenever I spin up a new brainstorm instance. It keeps track of kinds 0, 3, 1984 and 10000 just for this purpose. Should yield ~ 250k pubkeys connected via ~ 24 million follows.
Looks like what you’ve vibe coded is pretty comprehensive. All you’d have to add is NIP-85 support and you’d have a fully fledged Personalized Trust Metric Service Provider! Excellent entry for the WoTathon!🔥
I see that CozoDB supports PageRank, but looks like it only supports global, not personalized. Neo4j, memgraph and ArangoDB are the open source graph dbs that I know of that support personalized PR. Have you looked at ArangoDB? That’s one I have not looked into.
I'll have to try out a real world test this weekend and report back. I have a lot of Nostr catch up to do. So far the relay works fine but I have a bug in the sync to sort out. When is the deadline for the hackathon? I'm more interested in listening to presentation than submitting.
Our first community call will be Nov 20. Probably aim to have teams and projects lined up by mid January and run through until April.
btw I like the idea of a hybrid solution. Brainstorm is essentially a hybrid, with strfry and neo4j on a single server.