Initial Anoma applications to write in Juvix

Protocol Design
1

I spent some time thinking about what applications we should start to try to implement. Many applications are still woefully underspecified, so I think we should choose based on the dual criteria of relevance and clarity of existing specification documents. I’ve come up with the following list, on which I now want to ask the Juvix team for feedback.

  • Multichat
    • Described in an upcoming blog post by Patrick (ask him).
    • The main things to implement here would be channels, permissions, and messages.
  • Promise Graph
    • Specified here.
    • The main concept would be to implement tasks as described in this document as resources, with update rules as specified, and token payments conditional on task completion.
  • Knowledge Graph (w/CRDTs)
    • Described a bit here.
    • The main things to implement here are CRDTs, permissions, and doubly-linked pages.
  • Kudos
    • Described a bit here.
    • We can start simple - with kudo denominations, liquidity positions, swaps, automated flow / transfers - and build more functionality over time.
  • Public Signal
    • Described a bit here.
    • This depends on parts of Kudos.
  • Chess Tournament
    • Described a bit here.
    • The basic concept is that users can play chess matches against each other, where Anoma enforces the rules of chess, permissions of who can play what moves, timed clocks, etc. Users can also stake tokens before a game, and the winner takes the whole pot. Future application versions could integrate tournaments, ratings, and more complex multi-game rules.
  • Type-Checked Git
    • Described a bit here.
    • We could start with a very very simple language (not Juvix itself - like the simply-typed lambda calculus, say) as a demonstration of the concept.

Juvix folks - @paulcadman @jan @Lukasz - let me know what you think, especially what’s clear here and what isn’t in terms of knowing approximately what to implement.

4 Likes
2

In order to implement any of these applications we need support (possibly from D
or Patrick) to understand how to encode applications in terms of Anoma resource
machine primitives (Resource, Transaction, Logic Function).

The Kudos
pseudocode
is a good start but some details of the encoding still need to be worked out.

Our suggestion for collaboration is a series of paired programming sessions
where we try to code up an application in stages together.

We’d prefer to work on simple applications first and build them up with
additional features.

We could use the following steps to build up a multichat application:

  • An echo server. i.e a user broadcasts a message to themselves
  • Add support for a second user, users share messages between each other
  • Add support for n users, users can see all messages broadcast, can join an existing chat
  • Add support for channels (user can filter messages they see)
  • Add support for private messages (user can make messages available to a subset of users)
  • …
  • multichat
3 Likes
3

Makes sense - I also like the idea of pair design/programming sessions. @apriori and @degregat - what do you think you understand the best of these / what do you think you would be able to help the Juvix team implement?

From my perspective, I think I could help the most with:

  • Promise Graph
  • Chess Tournament
  • Type-Checked Git
  • Kudos (if necessary)
1 Like
4

@jonathan and I are gonna co-write an ART report (deadline on may 13th), but we can do some pairing sessions (@paulcadman) anytime in case you’re blocked.

I’m also happy to review designs for multichat (@apriori) to help bridge the gap between user directed functionalities and infrastructure.

1 Like