I havenāt looked at relay implementations in a while. I assume you know about awesome-nostr repo tracking all the projects? thatās my go to for what others are doing.
Yeah I think itās perfect for that!
The cypher queries for those should be pretty straightforward. Iām currently working on scaling my deployment of a neo4j db and making it more performant. Open to trading notes if you start using neo4j!
Anybody have a favorite chat option for open-source projects, for the devs to chat with dev and non-dev users? Iāve used Gitter in the past but wasnāt the biggest fan. Discord is popular. Something Nostr-based thatās easy for new users would be ideal.
GM & Happy Halloween! š
nostr:npub1az9xj85cmxv8e9j9y80lvqp97crsqdu2fpu3srwthd99qfu9qsgstam8y8 nostr:npub17304velluajf6lylvjynpj2f3ndg396w063gj2gef5qk0nwtcyjqfj9yky I noticed you donāt have a āsystemā parameter or role for using your API - is that intentional and if so, are you planning to offer an alternative?
Yesterday we were playing around with ideas at nostr:npub1s0veng2gvfwr62acrxhnqexq76sj6ldg3a5t935jy8e6w3shr5vsnwrmq5 , we needed something to preserve anonymity for blossom users that communicate with DVMs.
š¢ Introducing Onion-routing for event publishing
This introduces insane privacy guarantees, someone can publish an event and not even the relay they are publishing from can now it's them, nor their IP address.
Technically this works very similar to Lightning, the sender constructs a route of pubkeys and can bounce around the message through pubkeys willing to route for them.
The sender can include small ecash tokens inside each onion layer to pay for the routing.
No hop in the route until the last one knows what they are routing, who its coming from and the sender very explicitly defines through which relays it should hop.
(for the sake of debugging, I built a traceroute-like view, so the sender can see the event being bounced around the different relays; in real conditions a sender wouldn't use that to preserve privacy)
Think of this like tor, just faster.
nostr:note1q8rnnu4ss798ue88400r5ytej50uzhx87d775q6jev7hs64tj2ksf2nkh2
So cool, been simmering on this problem for a while and exciting to see this solution!!
GM
Depends on the group of people. Mostly I donāt because itās either irrelevant or convention not to use Dr. for that group. Sometimes though, a conversation before and after I mention I have a PhD is wildly different.
So, if itās a kind of fancy or prestigious event in any way, and people donāt know you well, I would use it. Otherwise probably not.
awesome thanks, what I had tried was from the popup of the personās profile. Glad to know the full profile has this!
I get this a lot. I now lead conversations with āNostr isnāt a companyā
nostr:npub1n0sturny6w9zn2wwexju3m6asu7zh7jnv2jt2kx6tlmfhs7thq0qnflahe have you thought about adding a dropdown on a personās profile that lets you add them to one or more of your lists?
I just tried after making a new list and saw someone I wanted to add to it
Would be fun to plot this against the interest rates with maybe a red or green vertical bar
Neat, thanks. I have another follow up question based on when I tried to use off the shelf clients (damus, iris, snort) with a single private relay and kept seeing events leak into public relaysā¦ are you worrying about the problem of using existing clients and preventing them from re broadcasting notes to relays which might be hardcoded (or cached maybe) in the client code?
Back when I tried using a single private relay between multiple off the shelf clients, my process was:
1. Download a client
2. Remove all initial relays in settings
3. Add my private relay
4. Use the app
And I couldnāt get events to stay off the public relays.
Granted this was a while ago, and if a client can render an event, then it necessarily has everything it needs to send it elsewhere and a code audit might be the only actual solution.
Anyway curious if youāve thought on this and are focusing or testing this problem at all?
People seem to be excited about my new project, Flotilla. It's still very much a WIP (probably a month out from MVP), but since it's been discovered I figured I'd go ahead and introduce it.
My goal for Coracle has for a long time been to support local in-person communities by replicating Facebook's events, groups, and marketplace. I've come to realize a few things about this project:
- Facebook is not the gold standard. In fact, people hate Facebook.
- There are many kinds of groups, for many different use cases.
- Very small chat groups work for most use cases.
- For almost all other groups, good moderation is key.
- Decentralization for groups works differently from decentralization for microblogging. Microblogging use cases benefit from simultaneous use of multiple relays. Community group use cases (in contrast to reddit-style groups) benefit from a single relay per group.
This is just the barest summary of what I've learned. But it's all in line with my long-held intuition that relays are, and should be, special. To that end, I'm creating a new client built around the dumbest form of communities that can be created: relays as communities.
Lots of code and specs need to be written to make this work, and as with Coracle, it'll be possible to host your own flotilla instance that only talks to a single relay, as well as use flotilla on desktop and mobile as a PWA and APK.
See the dev preview at https://flotilla.coracle.social. If you're interested in contributing, I've created several issues on the repository that should be good for first-time contributors: https://github.com/coracle-social/flotilla/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22
Love it - what about āmultiple relays run by individuals in the groupā rather than a single relay? That way you get better uptime, etc. or does trying to have multiple relays just make it harder?
Do you mind elaborating on what you mean by āregistering NIPs 5000-5999ā?
Using a kind number is as simple as broadcasting events with that kind, thereās nothing else required. You donāt need to submit a PR to a NIP on the Nostr GitHub repo.
One intended (although maybe not obvious) use case of DVMDash is to browse existing kind numbers being used, so you can know which ones are already taken if you think you need a new one.
Yeah, there hasnāt been good documentation or guides yet. Thereās a lot of work to do there
For your latter point, I feel itās already permissionless. To make a new kindā¦ you just do it lol (literally just start sending new events with the new kind in whatever format you want). Thatās why I had to build DVMDash, because the only way to know what kinds are out there being used by DVMs is to ask relays. There arenāt any nips for individual kinds between 5000-5999.
Regarding why not ākind 0ā profile events and NIP-89 insteadā¦ itās just a design decision to help make it easier for people building and using DVMs to know they are working with DVMs. If folks were using kind 0, how would you distinguish DVMs from
Humans when you want to find DVMs? Youād have to do something extra and that could make kind 0 events messyā¦. And NIP-89 is already quite an elegant solution, and happens to solve DVM āprofilesā too.
Iām with you 1000% about the ālet 1000 flowers bloomā. Iām preparing for us to have millions of DVMs.
Everything so far is just guidance. Thereās a balance of ālet 1000 flowers bloomā and also I want to be able to find and use all these flowers along with everyone else. Anyone can do anything (you can put computation behind a kind 0 profile) but if you follow the DVM spec youāre getting the benefits of that (sub) protocol, and the tools people are building to use DVMs are more likely to work for the computation youāre offering as well.
Decentralized networks of coordinated computational services, with any kind of payments, is hard. Even this year there are new scammy projects selling tokens and offering the what Nostr DVMs do, but much more centralized. Iām bullish on DVMs, thereās just a bit more infrastructure, docs, and core library work that will make super simple for devs to pick up.
š«
Iām curious what would be simpler than DVMs as they are now, do you have any ideas?
Letās say you attach an npub to some computation. Thatās 33% of what a DVM is.
How will people find out about it? Will you post a kind 0 profile like humans do? Or do a kind 31990 announcement in NIP-89? Now youāre at 66% of what makes a DVM.
How will people or services use your computation? Maybe you decide you need a special kind of format for the input to the computation, so you pick, oh I donāt know, kind 5123 and a spec of how the input data should be laid out. Now you have 100% of what a DVM is.
DVMs are the natural extension to having paid computational services behind npubs. They arenāt unnecessarily complex, quite the opposite.
nostr:note1wjmfxpjtekaruuk9re6c6ertaxm8ucd7t8rlqmzw67m8x0y4zuzse0cs4k
Cool! I'll play with it.
I'm with you on agents communicating over nostr. openagents.com and fewsats.com are the best examples of this vision I've seen so far. cc nostr:npub1tlv67m7xvlyplzexuynmfpguvyet0sjffce3y8vu0suuyuwgzauqjk7fdm
I guess DVMs as well, though I've yet to find a user friendly way to interact with these - what's the best DVM client right now? cc nostr:npub1mgvwnpsqgrem7jfcwm7pdvdfz2h95mm04r23t8pau2uzxwsdnpgs0gpdjc nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft
DVMs are more infrastructure imo, I donāt see them as something users will interact with directly (at least for most DVMs). The most used DVM right now is feed sorting algorithms, and clients make this user friendly and call the DVMs in the background (the user may not even know itās DVMs that are doing the work).
We havenāt really had multi DVM use cases yet (although folks are working on them).
I think of DVMs as modules that could comprise agents, and the space is still so early. For example, we need libraries where you can call a DVM just like you would call an API (a python library for this is on my to do list).
Many people building agents are using lots of APIs right? DVMs would replace these API calls and offer some neat tradeoffs.