nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft nostr:npub1mz3vx0ew9le6n48l9f2e8u745k0fzel6thksv0gwfxy3wanprcxq79mymx I updated NIP 90.md PR so that customer feedback is a kind:7, FYI

https://github.com/nostr-protocol/nips/pull/985

Could we make NIP-25 Reactions include arbitrary strings like “this worked but took too long” or numbers like “96” ? Terrible idea?

Currently the spec says it’s for emoji or ‘+’ or ‘-‘

I want to expand it so we can give DVMs the reactions they deserve (with flexibility on the amount of detail)

https://github.com/nostr-protocol/nips/blob/8331354947f2d577e13eb5da4a56133071cb1019/25.md

* RAG’d, not fine-tuned. Although that might work too

Oh boy I could really use an LLM fine-tuned on the NIPS docs right now.

Data Vending Machine from NIP-90 https://github.com/nostr-protocol/nips/blob/master/90.md

DVMs will help clients and relays be lighter, by offloading computation.

Algorithms for sorting your feed could be done via DVMs.

If you’re interested in AI, Rao is one of the best perspectives to have. Cuts directly through the hype and his lab has lots of papers to back up his claims.

Not on Nostr yet, for now Twitter and LinkedIn seem to be where he posts

https://www.linkedin.com/posts/subbarao-kambhampati-3260708_doesnt-the-fact-that-llms-can-write-code-activity-7149835624160579584-kOsB?

nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft what I'd also like to do is see about updating NIP-89, possibly by adding a tag, where a DVM can ask for feedback in a particular format (liked/disliked, score between 1-5, score between 1-100, emojis, etc). But NIP-89 looks even more general than DVMs so unsure if it makes sense.

I have proposed an update to NIP-90 for a customer feedback event:

https://github.com/nostr-protocol/nips/pull/985

and created an issue on vendata.io to add a user interface element so a user can send a `customer-feedback` after the DVM has finished.

https://github.com/pablof7z/vendata.io/issues/5

nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft nostr:npub1mz3vx0ew9le6n48l9f2e8u745k0fzel6thksv0gwfxy3wanprcxq79mymx thoughts?

Well… an agent would probably also be a DVM.

There would be simple DVMs that are like single actions. This is largely what we have now. Generate an image from this string or translate this note.

Soon we’ll have DVMs that use other DVMs before responding to the user. And this could go on and on if the task is complex enough.

I think agents will be standalone, outside of clients and relays because they’ll probably be doing lots of work. That’s the nice thing about DVMs, they let you have compute outside of clients and relays.

If you didn't see the full slide deck, the link is here:

https://dtdannen.github.io/Coordinating_(DV)Machines_9JAN2023.pdf

(Warning - it’s a lot of content mashed together)

Generally, you can think of DVMs as being the “actions” or “tools” or “functions” that an agent would call. (These are terms other projects are using; OpenAI refers to them as tools and functions)

Once we have a multi-step DVM chain (like a DVM passes it’s output to another DVM before the final response is given back to the user) then we have an equivalent to a hardcoded LangChain agent.

More flexible agents will choose dynamically which DVMs to use, in which order, to solve problems. That’s where things will get very interesting.

If a client chooses to make a new feature via DVM, then other clients could adopt the feature quickly.

Consider recommending new people to follow on Nostr. Each client could implement their own version, or instead one person could make a DVM that other clients hit to get the data.

DVMs may cost money but paying per each request to the DVM probably doesn’t always make sense. “Salaried” DVMs might be a solution.

Client subscription fees could cover DVM fees. Free clients wouldn’t have the paid DVM features.

Network effects would be insane here!

nostr:note1ghv96hsk0udgyr28kf8p7lc0nhyqgzpadpyqafctmd5a8j8ktjfsz4s9cv

This seems to be the clearest indicator that the model (GPT4) is deciding which functions to be called.

It’s interesting how actions are chosen across different LLM agents.

Judging from the description on OpenAI's website, the decision of which function (aka tool) to use is decided by the model (i.e. GPT4) based on the user’s incoming message and chat (thread) history.

“In this example, we define a single function get_current_weather. The model calls the function multiple times, and after sending the function response back to the model, we let it decide the next step. It responded with a user-facing message which was telling the user the temperature in San Francisco, Tokyo, and Paris. Depending on the query, it may choose to call a function again.

If you want to force the model to call a specific function you can do so by setting tool_choice with a specific function name. You can also force the model to generate a user-facing message by setting tool_choice: "none". Note that the default behavior (tool_choice: "auto") is for the model to decide on its own whether to call a function and if so which function to call.”

See https://platform.openai.com/docs/guides/function-calling

Happy new year #Nostr ! 2023 was incredible, can’t wait for 2024!

Has anyone made a bot that pings you when someone has posted to a community you are moderating, so you can immediately review it?

I started a community about ai-papers and missed a post from someone a few weeks ago. I didn’t get a notification in Nostur or Damus.

If this doesn’t exist yet, I may try my hand at setting it up.

Interesting, thanks. Appreciate all the work you’re doing!

Got it, thank you!

What problems were fixed? The limitations on the README were helpful but I wish it also included what issues were successfully addressed that prior DM implementation didn’t have

These are the current limitations from the Readme:

“On its own, messages sent using this scheme has a number of important shortcomings:

No deniability: it is possible to prove an event was signed by a particular key

No forward secrecy: when a key is compromised, it is possible to decrypt all previous conversations

No post-compromise security: when a key is compromised, it is possible to decrypt all future conversations

No post-quantum security: a powerful quantum computer would be able to decrypt the messages

IP address leak: user IP may be seen by relays and all intermediaries between user and relay

Date leak: created_at is public, since it is a part of NIP 01 event

Limited message size leak: padding only partially obscures true message length

No attachments: they are not supported”

Does this reduce or eliminate the problem that others can see who is talking even if they can’t see the contents with original DMs?