Potential ways for developers to build on DAOhaus

Warcamp (DAOhaus Core Contributors)
#1

What are all the potential ways community developers can build on, for, and with DAOhaus?

Built Type Description Examples
DAOhaus Apps Bolt-on applications that use the DAOhaus core platform to undergird higher level use cases. In other words, apps that create new use cases that are only possible because of the existence of a robust DAO and a platform to operate it. Yeeter, Daogroni, etc
DAOhaus Extensions Bolt-on applications that extend and support the DAOhaus platform. In other words, apps that make operating a DAO on DAOhaus easier, more effective, etc. There may be some overlap between this and the above category. DAO Books
Boosts Plug-ins that extend or modify DAOhaus core apps. In other words, new features that DAOs can add to their main DAOhaus interface. Discord boost, WrapNZap, Disperse, etc
Read External apps read data from DAOhaus subgraph(s). DAOhaus Explore, DeepDAO, Democracy Earth, etc
Write External apps that can write data to DAOhaus DAOs or other contracts. Such apps may create proposals to DAOhaus DAOs. potentially: Sobol, Nestr, etc.
Infrastructure Integrating other protocols into DAOhaus core infrastructure, thereby making them available for other developers to use in the above build types. potentially: Orca Protocol, Lit Protocol, etc

I am almost certainly missing some types here. What else is there?

Developing a better understanding of the array of possibilities here will help us with our platform strategy and architecture as well as our devrel activities.

2 Likes
#2

This seems pretty thorough to me! I’m thinking that with v3 we may see other use cases as well where folks use our npm packages. For example, someone may want to use our component library, feature-ui (such as the connect wallet), or data package as utilities in an app that doesn’t necessarily integrate with us.

1 Like
#3

Good point.

Beyond continuing to list out any types not yet captured here, I think an important next step is to map out the value flows associated with each type. The types that bring value into the DAOhaus ecosystem/economy are the ones we really want to focus on.

1 Like
#4

I spoke with the Nestr team yesterday (Joost & Julio) and what they’re working on is like a metadata wrapper system for DAOhaus proposals. The proposals are scraped and become a “Nest” (their term for the nestable units of organization in Nestr) and you can add tags to it, put it inside other things, put things inside of it, etc. So viewing proposals, but also a system for wrapping project management around proposals.

Technically falls into the “read” category but also kinda matches the description for Extensions & Apps.

Figured I’d give you that so you could puzzle how that fits into your categories. Looks good!

1 Like
#5

These all work for me. However, there’s a couple distinctions that I’d make.

Categories

If I’m being nitpicky, I’d say that from a tech standpoint there’s really 3 ways to build.

  • Standalone app (includes read, write, extensions)
  • Boost. There should be probably be a sub-distinction between boosts that wrap ACE with ui legos, and custom Web2-ish integrations like the discord boost.
  • Custom: Where we bring in new UI or pages for a boost. Historically, everything had fallen into this category. We’re looking to minimize this. However, all boosts have some small degree of custom work involved (ex. Poster boost had a new page with cards, etc).

Many options will can use varying degrees of each option.

I would say that we should push for options that use the least amount of custom work.

Standalone apps have really emerged as a winning strategy. It minimizes load on the app and maintenance, let devs build how they want, and provide new rich experiences for users.

Boosts are good if we stick to ACE and limit custom functionality. Also, the learning load for boost devs is pretty high, so their experience factors into it as well.

Custom is like pollution, it’s necessary to some degree for everything, but it should be reduced as much as possible.

2 Likes
#6

At a higher level the potential ways for developers to build on DAOhaus are:

  • Fix bugs for the community
  • Build tools using our infrastructure
  • Contribute to the core

Drilling into building tools using our infrastructure I like the break down of Apps, Extensions and Boosts. Wonder if Extensions and Boosts could be combined. It seems Read and Write are attributes of Apps and Extensions. But I guess those features could be used for other applications.

Would be a good exercise to explore these examples in further detail. Potentially writing a case study for each. Breaking down why it exists, who manages it and how it fits into the ecosystem would be helpful in identifying themes and promoting what is currently available. It would also demonstrate what is possible in a meaningful way.

Need to figure out a way to illustrate it is not necessary for other projects to re-create the wheel. Our protocol for managing membership, proposals and treasuries is on-chain and battle tested.

It becomes exponentially powerful when developers customize and enhance it to solve the specific problems of their community while benefitting the entire ecosystem.

Would also be nice to highlight where there are opportunities for other projects to try and create something else. Wallets and treasuries immediately come to mind. We currently use Gnosis Safe but that does not mean another team should not try to build a better bank.

Here is a recent breakdown of Boost activations that may be helpful:

boost-activations

2 Likes
#7

Thanks all for the comments and thoughts! I love when we get on a long-form communications roll :slight_smile:

They’ve inspired a few thoughts, but I’ll start with one:

Categorization

There are several dimensions on which to categorize these build types.

  1. Technical, ie by where code for the new thing is deployed.
  2. Use Cases, ie by where and for whom the new thing is meant to create value. This framing is probably the most relevant for platform & product strategy
  3. Value Flows, ie by the source and destination of value flows as a result of the new thing

There are also several decision levels in which understanding build types is relevant / informative:

  • A. High level platform & product strategy
  • B. Platform & product architecture
  • C. DAOhaus economy and marketplace protocol design

Here’s how I’d line characterize the relevancy of each framing wrt those decision levels:
:green_circle: high relevancy, :yellow_circle: medium relevancy, and :purple_circle: low relevancy

A. Product Strategy B. Platform Architecture C. Marketplace Protocol Design
1. Technical :yellow_circle: :green_circle: :purple_circle:
2. Use cases :green_circle: :yellow_circle: :yellow_circle:
3. Value flows :yellow_circle: :yellow_circle: :green_circle:

While my original categorization doesn’t fit perfectly or wholly into either of these dimensions, in retrospect my intent was mostly aligned with (2) Use Cases, since my mindset right now is mostly on (A) Product Strategy.

So, revisiting the (2) Use Cases dimension with more intent, here’s how I’d categorize the build types:

  • DAOhaus Apps – use cases are primarily about things only possible with a robust DAO underneath
  • Boosts – use cases are primarily about improving DAO operations, including both DAOhaus Extensions (bolt-on apps) and Integrated Boosts.
  • Read – use cases are primarily about surfacing information about or running analytics on DAOs
  • Write – use cases are primarily about enabling fully external apps to interact with DAOhaus DAOs as a piece of what they do.
  • Infrastructure – use cases are primarily developer-focused, expanding the toolset developers have access to when building any of the above.

I have some more thoughts here, but wanted to get this out before I head into a call.