deazy

Basically this is what I think it is,

Shared context that can act as independent shards of (mini) contexts, i.e Sub-global attention blocks or "sub-context experts" that can operate somewhat independently and then scale up or compose into a larger global attention as a paradigm for handling extremely long contexts.

Trying to see if this can be tested in some way at small scale, its worth a try if it can work, but requires some engineering to make it possible.

Great adjacent read.

Open Problems in Cooperative AI

From Centre for the Governance of AI, Future of Humanity Institute, University of Oxford, DeepMind, University of Waterloo

https://arxiv.org/abs/2012.08630

Casual Peer Review:

Conceptual leap – could be considered a spark of genius or at least high creativity.

Framework serves more as a philosophical guideline or a set of desired emergent properties for future MAS, rather than offering concrete algorithmic or architectural solutions

Provides interesting research questions and potential directions for MARL (e.g., exploring identity-based intrinsic motivation), but practical implementation requires significant breakthroughs in representation learning and reward design.

The framework serves as a rich source of phenomena for BGT/EGT researchers to target. It motivates the need for more sophisticated models incorporating dynamic identity and group-level agency but doesn't provide those models itself. It pushes the application boundaries of existing game theory.

It currently serves more as a thought-provoking extension than a developed technical proposal.

What is the most effective way to make people (humans) come together as a whole and achieve a common goal or defeat a common enemy or solve a common problem.

Forging the Collective: Abstracting the Mechanism of Collective Formation, with Hindavi Swaraj as its Landmark Manifestation, for Cooperative AI Systems (AI/ASI/ALF)

This is a part of my hobby research into artificial life forms, a recent one, this is to showcase the brilliance, sophistication and surprisingly effective thing that came/occured out of India (Maharashtra) (Indigenous), in 17th Century, that everyone should know, celebrate and be proud of and be amazed by, that serves as a Landmark Manifestation of Foundation/Formation of a Collective, read and you might understand / realize few things.

This is a conceptual framework for Cooperative AI and Multi-Agent Systems (MAS) more of a Ideas piece or a think piece, conceptual and inspirational in nature.

I was hoping for a response, but no one bothered. I had noted the following when I made that comment and will just wrap up from my end so this could be used by others for reference later.

I'm skeptical that the re-execution approach can scale for complex queries, the latency and throughput improvements would be offseted by the computational cost and bottlenecks introduced for achieving it via its reactivity mechanism (query subscription), this might not work at scale and serve niche use cases.

There are various ways throughput and latency for kv stores can be improved, so bar is really high here.

The messaging with Dice seems unclear and confusing to describe its purpose/use-cases over alternatives, or how it achieves them, which could just be how it's marketed. But it seems to be a collection of ideas and a WIP project.

I think reducing data fetching complexity and complex key dependencies for end clients could be appealing, and it would be great to have it at the KV store level, but there is no reason this type of reactivity can't be implemented on top of various clients for existing KV stores (like Redis). And basic WATCH with transactions are even offered out of the box in them.

Deno kv seem nice but its vendor locked, also there are many others like dragonfly, valkey etc, redis could still work, even something over sqlite can work, deno has a selfhosted kv on top of sqlite - https://github.com/denoland/denokv

Also with dice its creator had made this talk

https://hasgeek.com/rootconf/2024/sub/how-we-made-dicedb-a-t...

From that and the thread so far it seems, they want to make some super cache by building a realtime multi-threaded kv store, improving latency and reducing its read load via its reactivity mechanism. Solving the problem of cache invalidation.

Not sure how this will be achieved but there is no harm in trying. From what is said and shared, rationale behind this design and its tradeoffs are not clear, code could be fixed/improved but providing clarity on this is essential for adoption.

Looking at the diceDB code base, I have few questions regarding its design, I'm asking this to understand the project's goals and design rationale. Anyone feel free to help me understand this.

I could be wrong but the primary in-memory storage appears to be a standard Go map with locking. Is this a temporary choice for iterative development, and is there a longer-term plan to adopt a more optimized or custom data structure ?

I find the DiceDB's reactivity mechanism very intriguing, particularly the "re-execution" of the entire watch command (i.e re-running GET.WATCH mykey on key modification), it's an intriguing design choice.

From what I understand is the Eval func executes client side commands this seem to be laying foundation for more complex watch command that can be evaluated before sending notifications to clients.

But I have the following question.

What is the primary motivation behind re-executing the entire command, as opposed to simply notifying clients of a key change (as in Redis Pub/Sub or streams)? Is the intent to simplify client-side logic by handling complex key dependencies on the server?

Given that re-execution seems computationally expensive, especially with multiple watchers or more complex (hypothetical) watch commands, how are potential performance bottlenecks addressed?

How does this "re-execution" approach compare in terms of scalability and consistency to more established methods like server-side logic (e.g., Lua scripts in Redis) or change data capture (CDC) ?

Are there plans to support more complex watch commands beyond GET.WATCH (e.g. JSON.GET.WATCH), and how would re-execution scale in those cases?

I'm curious about the trade-offs considered in choosing this design and how it aligns with the project's overall goals. Any insights into these design decisions would help me understand its use-cases.

Thanks

In case its not clear its a blueprint to build the thing not the implementation for the actual thing.

For example, to see how it works or if it works, you can directly use the post in a prompt itself, check the results for yourself, here is an example of it

https://chatgpt.com/share/67d24dc5-8c24-8006-8a0d-392aa8263b...

Sharing this, hoping someone finds this useful, also would like to hear what others think about this approach.

This gist outlines a two-phase approach to generating production-ready code using AI.

It emphasizes using pseudo-code, example code, and a modular design to guide AI code generation.

Phase 1 focuses on creating a functional prototype, while Phase 2 refines it into production-ready code.

It also links to a separate document with related best practices.

https://gist.github.com/ditpoo/387d2fc94a1bbfbe0f2312686eb09...