feat: DAO SDK

[n0izn0iz]

This implement a DAO SDK inspired by DA0-DA0

The code in this PR has been extracted from #1154 and cleaned (reviews on the previous PR should have been addressed)

It includes:

• Interfaces for the DAO gno.land/p/demo/dao_maker/dao_interfaces
• A reference implementation for the core of the DAO gno.land/p/demo/dao_maker/dao_core
• A membership-based voting module gno.land/p/demo/dao_maker/dao_voting_group
• A single-choice proposal module gno.land/p/demo/dao_maker/dao_proposal_single
• An example DAO gno.land/r/demo/dao_maker/dao_realm
• A registry to dynamically interact with any registered DAO using it's address gno.land/r/demo/dao_maker/dao_registry

For usage see the tutorial, it is integrated into docusaurus

---

There is an example membership-based DAO at gno.land/r/demo/teritori/dao_realm that can administer itself and a grc20 token at gno.land/r/demo/teritori/tori

Here is it's GnoWeb Render:

---

This powers the "Organizations" feature of Teritori dApp on Gno as shown below

The DAO creation UI uses a Gno template and instantiates a new realm.

Contributors' checklist...

• Added new tests, or not needed, or not feasible
• Provided an example (e.g. screenshot) to aid review or the PR is self-explanatory
• Updated the official documentation or not needed
• No breaking changes were made, or a BREAKING CHANGE: xxx message was included in the description
• Added references to related issues and PRs
• Provided any useful hints for running manual tests
• Added new benchmarks to generated graphs, if any. More info here.

[n0izn0iz]

Thanks for the review @leohhhn, I addressed your comments

I have two remarks to spark discussion around guidelines:

• Adding periods everywhere is considered a bad ux practice by google

• Tutorials should be playful instead of formal

  The use of humor in the college classroom has been researched extensively (see Segrist & Hupp, 2015 who summarized 41 years of literature on humor in the college classroom) and has been shown to have many benefits for students (Banas, Dunbar, Rodriguez & Liu, 2011; Garner, 2006; Huss & Estep, 2016; Pollio, 2002), some of which are:
  An increase in learning.
  An increase in self-motivation.
  An increase in class attendance.
  An increase in test performance.
  An increase in divergent thinking.
  An increase of interest in learning.
  A reduction of anxiety and stress in dealing with difficult material.
  The creation of a positive social and emotional learning environment.
  The creation of a common psychological bond between students and faculty.

[elix1er]

impressive work, keep grinding

[leohhhn]

Left some minor suggestions to the docs page. Otherwise we should be good to go.

Sorry for the delay, and great work.

[moul]

what about using users.Resolve(aon).IsValid()?

[n0izn0iz]

can't call the realm method users.Resolve from a p package

[moul]

can you add more info about what is this package about?

it looks like something that should be located in p/demo/havl.

and add some tests.

-> could eventually have it's own PR.

[moul]

The current p/demo/json library should be suitable for your needs.

I'm against having any JSON library written in userland because I expect that we can use @gfanton's #1776 and avoid any boilerplate code that isn't either for humans (rendering) or for other contracts (imports). Generally, anything about marshalling doesn't fall into these categories.

In the meantime, you can reuse the existing JSON library if needed. However, as soon as possible, I expect we can delete it completely. Additionally, if possible, I expect we don't merge any new JSON library in the meantime.

[n0izn0iz]

this extends p/demo/json

[moul]

Suggested change

	sb.WriteString(strconv.FormatUint(uint64(v.MemberCount(havl.Latest)), 10))
	sb.WriteString(ufmt.Sprintf("%d", havl.Latest))

[moul]

You can use avl.Tree.IterateByOffset.

[moul]

isn't avl.Tree.Size enough for you?

[moul]

can you move this to gno.land/r/teritori/tori?

[moul]

why is this needed?

[moul]

There are several interesting aspects in that PR, but there is too much work to review at the moment. Therefore, I will mark it as "request changes" to allow more time for a thorough review.

A high-level suggestion I can provide is to:

• Simplify the codebase by reducing the number of packages, files, functions, types, and boilerplate, and avoiding the use of JSON, etc. Consider merging some packages together.
• Improve the naming conventions. For instance, use more specific names like "Teritori Realms" and "Daomaker" (a better name could facilitate faster merging, as "Daomaker" is currently too generic and sounds overly official, while "Teritori" would make it easier to integrate).