I've proposed a workshop and keynote at #Nostriga @Nostriga - please comment on them with a 👍 if you'd like to see them at the unconference! Workshop: "Tutorial on Data Vending Machines" - you will build a running DVM as part of this workshop!

GitHub

Tutorial on Data Vending Machines · Issue #29 · nostrworld/nostriga

Description What is this workshop about? Provide as many details as possible. This workshop will be a hands-on session where developers of all skil...

Keynote: "Superintelligence on Nostr" - I'll argue why Nostr has a chance at being the first widespread decentralized AI network, what the future might look like, and why it empowers the sovereign individual

If you have tried using LLMs to generate and execute code, you might appreciate this workshop paper we presented at @ ICML workshop on LLMs and Cognition. The primary contributions are 1) a Case-Based Reasoning approach to reducing LLM failures via dynamic, few shot prompting and 2) seven failure types that can cause generated code to fail. These failure types are more detailed than most benchmarks that evaluate LLM code generation; and since we didn't have an automated way to check for all of them, we performed the evaluation by hand 😅 Paper: https://openreview.net/pdf/f2d10bfca1b7d9f6f0a87144fee8e775cba6701a.pdf

DVM ecosystem just got an upgrade with proofs for DVM output; also nostr_sdk rocks View quoted note →

Are KINDs distinguished by their structure? If I turned an event for an arbitrary KIND into a graph where the graph structure matches the JSON structure, and the data types of nodes were colors, could I get a unique graph for each KIND? What if there was a tool where people can see if there is already a KIND that exists for them or if they need to create a new one. The tool would just pull as many different kinds as possible from relays, and you could take an example event and compare it against all existing ones based on structure and data types of nodes. It could remove the need for any single global list of KIND events, like the Nostr NIPS repo. I'm particularly interested as we have many more DVMs come into play and when someone wants to make a new DVM, they will need to decide whether to use an existing KIND or create a new one.

GM! Excited to see @npub1cr9c...lk4s on Nostr, welcome!

Some pretty graphs appeared while working on #nostr this morning:

Just like bitcoin had decades of academic publications behind it, so too does decentralized AI. Check out this 1990 book on Decentralized AI! No mention of blockchain 😂 https://shop.elsevier.com/books/decentralized-ai/demazeau/978-0-444-88705-4 Unfortunately it's behind a paywall...

Nostr is hilarious today

DVMs > APIs

Thank you @Don't Believe The Vibe 🌱🍋🍊 for making the default behavior on nostrdvm to use whatever relays the original request puts in the tags. 🍻

Thought I was experiencing an issue related to relays, ran a local bucket relay, problem solved! Thanks @hodlbod 🙏

GitHub

GitHub - coracle-social/bucket: A very simple relay for testing nostr clients

A very simple relay for testing nostr clients. Contribute to coracle-social/bucket development by creating an account on GitHub.

Pro tip - remove the “wss://“ normally in front of relay URLs when you use it

DVMs exist on Nostr at the same level as (all?) other users (aka humans). That’s a big deal.

Encrypted DVMs, as they are currently implemented, break one of the best features of the DVM process. What feature is that? Using kind numbers when asking for work rather than asking DVMs directly. I’m not sure what the solution is - perhaps the user requests the type of work to be done (which kind number and perhaps metadata such as size of data they have), then DVMs can respond as a sign they are interested, then the encrypted handshake can occur after the user chooses which DVM to use. It will be tempting to just select a DVM before making a request, and maybe the loss of flexibility and price competition isn’t enough to deter the temptation.