Autark Flock Proposal

agp

#1

Last year we won a Nest grant to develop a Planning Suite for Aragon which has been under production. And now we want to go all in and become a Flock team that focuses fully on building the Aragon ecosystem. We are calling this team “Autark”!

Autark sees the adoption of Aragon as a way of expediting the future of work and society; one tailored around worker-autonomy, solidarity, reclaiming freedom, reclaiming land, and ultimately the stewardship for Planet Earth and all of its citizens.

Check out our AGP and Flock proposal:

In the next few days we are going to share more about the work we have done on the Planning Suite (including a video demo), our team, and vision for the future!

Looking forward to feedback and also looking forward to your “Yes” vote later this month!


Internationalization
Community Initiative: Aragon Cooperative 🙌
Aragon Network Vote #1 Megathread
Aragon Network Vote #1 Megathread
#2

In the full proposal there are a number of milestones that I think are worth discussing in greater detail:

Cross-Application User Experience

This seems to address a challenge associated with developing Aragon Apps. I would love to see some discussion related to the pros-cons, would these changes make developing Aragon Apps easier? would it make certain types of application or UX decisions possible that are not currently possible, possible?

Contextual Discussions

This sounds really useful, discussion is really important in governance. However, it also feels like something that may be quite complex / costly to build on decentralized infrastructure and I wonder whether it makes sense at this stage to move that direction versus rely on centralized alternatives like github/forums that are loosely coupled. E.g. something put to a vote could provide a link to a discussion forum where the actual discussion could take place.

It would be interesting I think to explore the pros/cons and the marginal benefits of decentralizing and fully integrating this into the application at this stage.

Rich User Profiles

While Aragon One’s identity app will provide much-needed features; an identity is more than a name, bio, ENS domain, and avatar. We propose to expand identities to allow for more rich profiles. This will be useful as the network of organizations within Aragon grows and a freelancer culture develops. This supplementary data can be useful in assessing allegiances, expertise, and clout.

I think this is really cool, digging the future of work vibe. I think this aligns well with the planning suite stuff, though it does feel like user profiles makes more sense for user to manage externally from the Aragon client (ala 3box). Though it would be nice for address badges in the app to link to a users profile, or a summary of specific parts of the users profile.

Expanding Governance Possibilities

Implementing a reputation system within Aragon will expand governance possibilities and allow the usage of Aragon for reputation-based governance without requiring the integration of external applications such as Colony or DAOstack which can add security risks.

The most logical place to implement the reputation system will be within the Projects application. To support reputation, changes to the Token Manager will be required, to allow minting a special type of quasi-transferable tokens that can be transferred only by a whitelist of addresses (e.g. the Standard Bounties contract or a specific Aragon application). Additionally, the Projects app will have to be enhanced to allow multiple tokens to be allocated to bounties.

The end goal is that when a user completes a task using the Projects app, they can collect a variety of tokens – standard ERC-20s in addition to non-transferable reputation tokens.

This would be rad, while its currently “possible” to use the token manager to issue non-transferrable tokens that represent reputation, I think streamlining the UX of reputation issuance and integrating that with apps for assigning tasks is really high leverage. Would personally be very eager to use this!

At the moment, there are only two templates: Multisig and Democracy. To expand governance possibilities and allow for an easier user experience when a new DAO is being deployed, it will be beneficial to develop additional templates for the ecosystem. As part of this initiative we aim to create one additional template that will support reputation-based organizations.

I agree that the current templates are not all that useful, though I personally am a bit wary of going down the “add more templates route” as I think the power of Aragon as a platform is customizability/modularity – I made a suggestion for all organizations to start at the same blank slate, and then have onboarding guide users through installing apps and configuring permissions to meet their specific usecase. I would much rather see the process of customizing organizations improve over increasing the number of static templates available.

Data Storage and Standards

This feels like an important question for all web3 dapps, though I wonder if it makes sense for us to address at this time, I know there is a lot of external infrastructure work happening right now (e.g the graph, filecoin, swarm) and wonder if we can postpone our need for such things until those projects mature as I think trying to take this on ourselves could easily balloon in scope.

Would love to hear thoughts from people who are more in the know about the challenge and needs (e.g. actual devs :D).

DAO Identity

I like this, it seems like a common ask from users to be able to customize the app to some degree. I think simple and high leverage things would be the ability to pin a specific app to the home page that loads by default, the ability to define a custom logo, and have an onboarding/wiki page app that allows the organization to present information to its users/community when they first launch the organization.

I’m less convinced that we need theme support, especially early on.

Rather than theme support, it feels like internationalization would be in a similar vein/scope and provide a lot more value.

Rewards Application and Planning Suite

The Rewards Application and Planning Suite is I think one of the most important nest projects, but I think many may not be aware of the scope of the project and what has already been completed. It would be great to showcase that a bit more and highlight how it fits in with some of these other initiatives.

I see finishing the planning suite deliverables and improving support for reputation management as potential catalysts for adoption for Aragon.


#3

Hi @lkngtn thank you for reviewing our proposal! If AGP-19 gets funded, Thomas O’Brien and I from Open Work Labs will be working on data storage and standards, so we’re happy to provide explanations and answer questions.

I agree with you - it’d be difficult to rely on newer web3 technologies like Swarm, Threads, OrbitDB, Filecoin, etc. (I would include 3box in that list as well). For this initial Flock proposal, we’ll likely implement a simple, traditional database to cache and index data as described in the short-term solution section of the document. The data would be duplicated on distributed storage and formatted according to open standards. We are leaning toward using IPFS for storage since it’s stable. This would be reasonably low lift, support features like profiles and discussions, and provide immediate benefits:

First, on-chain events can reliably link to off-chain data in IPFS. Content addressed data won’t change or disappear if at least one peer is sharing it. On-chain events that link to centralized sources can lose value if referenced data gets modified or becomes unavailable.

Second, the process of transitioning to fully distributed storage and open data standards becomes simpler. We wouldn’t need to reformat the data from centralized servers or identify proper standards and vocabularies all at once. These are things we can do gradually over time.

Third, data can become interoperable across DAOs and other open source projects. This is a rabbit hole of its own but one that Open Work Labs is working on outside of the grant as well.


#4

Thank you @lkngtn for all of the great questions and commentary. See my responses below!

Cross-Application User Experience

This seems to address a challenge associated with developing Aragon Apps. I would love to see some discussion related to the pros-cons, would these changes make developing Aragon Apps easier? would it make certain types of application or UX decisions possible that are not currently possible, possible?

For those unaware, Aragon apps are contained within the pink section in the image below, and there is a restriction of a one-to-one mapping between an Application and a contract. This means you are restricted to using a single solidity file for developing a single Aragon app. If you want to use two solidity files, this means that you have to create another app, and the way to access these functions will be by accessing this additional app via the left-navigation menu.

But that’s just not how software always works. It may be more logical for the additional functionality to be accessed within horizontal tabs that are located in the pink region, instead of vertical tabs in the wrapper region.

I think that from both a developer’s standpoint and a designer’s standpoint, providing the flexibility for an Aragon app to have multiple contracts is very important. One reason is that this is how applications are being developed today outside of the ecosystem.

Once you impose restrictions like this, it boxes the creativity of the designer which can also result in suboptimal UX patterns – to be molded around software limitations instead of user expectations. Since these limitations do not exist outside of Aragon, I am guessing that new developers into the ecosystem can also feel restricted by how they have to write code.

I think the proposed TCR app is a use case where this limitation results in a user experience that I think will be more confusing than it needs to be. See my thoughts on the TCR pattern on this Github thread.

Contextual Discussions

This sounds really useful, discussion is really important in governance. However, it also feels like something that may be quite complex / costly to build on decentralized infrastructure and I wonder whether it makes sense at this stage to move that direction versus rely on centralized alternatives like github/forums that are loosely coupled. E.g. something put to a vote could provide a link to a discussion forum where the actual discussion could take place.
It would be interesting I think to explore the pros/cons and the marginal benefits of decentralizing and fully integrating this into the application at this stage.

@Schwartz10 (Jon) covered a lot of reasoning for why we find moving towards a path of decentralization for discussion makes sense. But to reiterate, what we intend to accomplish in this initial 26 week period will not be fully decentralized as there will be an intermediate caching layer. Additionally, Aragon is already hosting non-smart contracts on IPFS, so I think that user inputted elements (such as profile data, discussion) also being hosted on IPFS is a logical move, especially if we want to create the optimal end-user experience.

One example of the inefficiencies of the current system can also be observed for the AGP process that is underway right now.

In the Github thread where the Association board is providing their approvals/rejections of the current AGPs, @jorge states:

I support AGP 14 and AGP 16 as they currently stand, but given that they only contain a Github link to another pull request that could be modified by the author, maintainers or Github itself it is too risky to sign such AGP. I will refrain from signing until the AGP text contains the proposal description.

He has a totally valid point (see my misstep here as well!). But this can also be avoided if we start to move down an IPFS or related path as far as how voting proposals work. Hence I think this is actually one of the most important features needed for Aragon, especially if we want to:
a) Make the proposer’s life easier (not requiring them to go somewhere else to upload to IPFS and then link it)
b) Remove the vector of a proposal being updated after submission - which helps to avoid unnecessary trips to the Aragon Court

A second example of why it is important to prioritize distributed storage for contextual discussions, is that the UX for submitting proposals for discussion is also very poor. Right now the pattern seems to be:

  1. Create an AGP which is a pull request
  2. Create a new discussion post in Aragon where that pull request is linked (See the first post in this thread for an example, which links to: https://github.com/aragon/AGPs/pull/19)

If you actually click on this pull request, it looks like the screenshot below.

A new Github user that is reviewing the proposal may be very confused on how to actually read the proposal.

Additionally, as a proposer who is creating a forum post to share the proposal for review, is there a better link I should post instead, so the user doesn’t have to dig around for the markdown file? Should I post a direct link to the file, like this instead? https://github.com/stellarmagnet/AGPs/blob/625e14306f3d27d19c25ce4299852837178c2f3f/AGPs/AGP-19.md

And should we instead have the discussion within Github?

There are actually too many possible paths that the proposer can take, that it’s going to result in really inconsistent behavior. The only way to avoid this is to actually design a more self-contained system as far as proposals and discussion goes. This means we should start think about integrating discussion into Aragon, sooner rather than later.

We already are relying on Github to maintain the integrity of the proposals. With our near-term solution, it does involve relying on trusted community member or partner organization to host the centralized caching layer, yet the great part is that the storage is distributed and we plan to move it in a direction where the devops provider can change, and then eventually made obsolete once we implement the long-term solution.

This is much better than relying on Github as the referenced data does not live in a centrally controlled database.

This initiative of ours is also very much related to this previous Nest proposal which hasn’t been fulfilled yet. But we are personally passionate about building a modular solution that can work for many discussion use cases.

The third benefit is that discussions on distributed storage will enable the “freedom to fork” as far as DAOs go. Right now forum.aragon.org can be thought of as a forum for a DAO - The Aragon Network. But if another DAO forms within this community, and wants to have an isolated forum, it would be difficult to copy/migrate the discussions due to the centralized nature of the database.

I think it’s important to think of this possibility and allow communities the freedom to migrate, yet not lose their past discussions. If discussions are hosted on distributed storage, and identities are mapped to Aragon identities instead of the identities used to sign up to forums, this will be much more seamless, clean, and future proof.

Rich User Profiles

I think this is really cool, digging the future of work vibe. I think this aligns well with the planning suite stuff, though it does feel like user profiles makes more sense for user to manage externally from the Aragon client (ala 3box). Though it would be nice for address badges in the app to link to a users profile, or a summary of specific parts of the users profile.

Removing external applications an end-user needs to interface with to participate in an organization should be a priority if we want to onboard folks from all walks of life. I am a maximalist in the sense that I hope everything can one day be self-contained within Aragon because it would advance the pillars of privacy, internationalization, and accessibility. Self-containment means conveniently giving a user the ability to edit and update their identity within the Aragon app; not restricting the user’s ability to migrate or manage this identity outside of Aragon. We will compare the use of 3box versus building a simple solution from scratch to achieve this goal. We plan to move on a solution that’s reliable with the lowest lift.

Expanding Governance Possibilities

I agree that the current templates are not all that useful, though I personally am a bit wary of going down the “add more templates route” as I think the power of Aragon as a platform is customizability/modularity – I made a suggestion for all organizations to start at the same blank slate, and then have onboarding guide users through installing apps and configuring permissions to meet their specific usecase. I would much rather see the process of customizing organizations improve over increasing the number of static templates available.

Now that I think of it more, I think “one wizard to rule them all” will be the more logical roadmap. This will be especially important if we want people to create DAOs in two minutes :slight_smile: So maybe this initiative can be to move toward a path of a single, master wizard? This would actually solve what you are proposing in that forum thread as well. I do really like the idea of starting with a blank slate organization.

Although still I think having a few pre-configured setups is OK. If we want pre-configured setups – I assume that means we need to still maintain some kind of template system. It’s just the setup wizard can have a more seamless and unified experience regardless of template. Eventually it would be awesome for community members to create setups using drag & drop and something more visual, and then save/publish the configuration in a “governance marketplace”.

It should be kind of like how wix makes it so easy to design a webpage without touching any code. So it is a good problem to think through: should we enhance the app center in general, or templates? Definitely something we can explore and jam on more. But if doing it the silver bullet app center way will take too long, I think spending something like two weeks to make some simple templates shouldn’t be thought of as that much of a distraction. It really matters what the timeline of the App Center is and how long we estimate the ideal solution would take to develop.

Data Storage and Standards

This feels like an important question for all web3 dapps, though I wonder if it makes sense for us to address at this time, I know there is a lot of external infrastructure work happening right now (e.g the graph, filecoin, swarm) and wonder if we can postpone our need for such things until those projects mature as I think trying to take this on ourselves could easily balloon in scope.

Would love to hear thoughts from people who are more in the know about the challenge and needs (e.g. actual devs :D).

See Jon’s response, and also my take above in the discussions/profiles sections.

DAO Identity

I like this, it seems like a common ask from users to be able to customize the app to some degree. I think simple and high leverage things would be the ability to pin a specific app to the home page that loads by default, the ability to define a custom logo, and have an onboarding/wiki page app that allows the organization to present information to its users/community when they first launch the organization.

I’m less convinced that we need theme support, especially early on.

Rather than theme support, it feels like internationalization would be in a similar vein/scope and provide a lot more value.

The ideas you mention are definitely in tune with some of the thoughts I have about the About app mentioned in the proposal. We can definitely also look into the aspect of pinning apps in the Home tab, or making the Home much more flexible in general (think a customizable dashboard, with widgets).

I would actually love to do a poll in the next week from Aragon Cooperative members, adding our proposed Flock roadmap generally and our nice to haves, to see what the preferences are! Can we get the coop going before the vote? I’m just not sure if for the purpose of this 6 month period, we should action on the survey results, or if it’s something we consider more for the next cycle assuming we get to that stage.

Rewards Application and Planning Suite

The Rewards Application and Planning Suite is I think one of the most important nest projects, but I think many may not be aware of the scope of the project and what has already been completed. It would be great to showcase that a bit more and highlight how it fits in with some of these other initiatives.

I see finishing the planning suite deliverables and improving support for reputation management as potential catalysts for adoption for Aragon.

I am glad to hear that you find the Planning Suite as important as we do! We are trying super hard to have our Rinkeby demo going in the next couple days, and we plan to make a video going through what we have built and what is remaining. We will post a blog and also update this thread with that link - stay tuned.

In the meantime, for those unfamiliar, an overview of each app is here: https://www.autark.xyz/aragon-apps

As mentioned in the Flock, our focus will be to enhance the Project apps further to support multi-token bounties (including reputation tokens) and also completing the Rewards app which we are rolling into our Flock roadmap.

In general, we also plan to upgrade the components and patterns used in our apps to use what has been developed by A1 in the past 6 months, and contribute to Lorikeet time permitting - with new components we are developing such as a robust table toolbar.


#5

I’m imagining every other dapp dev saying the same thing about their dapp and cringing super hard at the thought of hundreds or thousands of devs re-implementing the same profile editing functionality in their dapp. My preference is to stay laser focused on building governance tools and leave other problems like auth, ID, stablecoins, decentralized storage, etc, to other projects that are focused on solving these problems.

Maybe to meet in the middle on this, there could be a standard modal that says something like “Hey we notice you don’t have an Ethereum Profile yet, would you like to create one?” And then the user can click “no” and proceed to the dapp or “yes” and go to the next page in the modal to add a profile before going back to the dapp. If the user needs to edit their profile, they could click a button to re-open the modal and make the change they want. This modal could be re-usable and easily re-styled so every dev can add it to their dapp with their own branding with a few lines of code, without having to re-invent the wheel over and over, preserving profile interoperability while making it easy for dapp users without a profile to create/ edit/ delete their own.


#6

I guess we all have different preferences and different visions for what Aragon is and for what Aragon can be. Is it okay for different Flock teams to have slightly different strategies? In designing a DAO right now – Space Decentral – we have a lot of community members that are new to the blockchain, new to using Github – there’s a lot of tool fatigue. Part of wanting more of a self-contained system is to make it easier for blockchain new comers to participate, especially people who aren’t software developers. I imagine what we are experiencing in Space Decentral will be the same for a lot of other communities. The blockchain community is still so small – there is a lot of adoption to come.

Self-contained doesn’t mean interaction with other apps/dapps would be cut off. Due to the decentralized nature of smart contracts, Actor app, etc there will be a lot we can do within Aragon that doesn’t require reinventing the wheel. This can be evidenced with the approach our team is already taking with the Projects app, where we are leveraging the StandardBounties smart contract developed by Bounties Network / ConsenSys.

And i’m not talking about us creating the web3 profile solution for the entire Ethereum ecosystem within Aragon. This is more about further fine-tuning identity/profiles specifically tailored for the case of human-work DAOs.

I think saying something like “leave other problems like… decentralized storage” to other projects seems to be ignoring the fact that building great governance tools will very likely require leveraging decentralized storage solutions – especially for Discussion – as you cannot properly govern without communication. Not to beat a dead horse, though. Since we plan to implement a storage solution for Discussion within Aragon, it will be trivial to solve it for profiles as they are much less complex than discussion threads.

Maybe to meet in the middle on this, there could be a standard modal that says something like “Hey we notice you don’t have an Ethereum Profile yet, would you like to create one?” And then the user can click “no” and proceed to the dapp or “yes” and go to the next page in the modal to add a profile before going back to the dapp. If the user needs to edit their profile, they could click a button to re-open the modal and make the change they want. This modal could be re-usable and easily re-styled so every dev can add it to their dapp with their own branding with a few lines of code, without having to re-invent the wheel over and over, preserving profile interoperability while making it easy for dapp users without a profile to create/ edit/ delete their own.

This sounds like a pretty good idea. As mentioned, we are going to be looking into 3box – but if there is a strong push to make 3box a requirement instead of a consideration, then that’s fine as well. I’d just encourage the Aragon identity app that is under development to also use 3box for display name, avatar, and bio, for the sake of consistency-- if this is the community consensus profile solution.


#7

I think saying something like “leave other problems like… decentralized storage” to other projects seems to be ignoring the fact that building great governance tools will very likely require leveraging decentralized storage solutions – especially for Discussion – as you cannot properly govern without communication.

I’m not at all opposed to leveraging technology other people have developed - on the contrary, that is exactly what I’m advocating. What I’m averse to is building a new bespoke profile/ ID solution from scratch when there are several working solutions already available for this.

I want one profile that’s interoperable across all the dapps I use. Maybe each dapp only uses a part of the profile, and some dapps extend and add fields/ metadata to the profile to accommodate for a new context. That’s fine. What I don’t want is to have a bunch of non-interoperable data silos hanging off my ethereum account and end up with the same ID schizophrenia and data fragmentation that exists in the web 2.0 world. And I definitely don’t want Aragon to contribute to such a frustrating outcome.

One name, one profile, one ID for all dapps. Keeping it simple. That is the user experience I want to have interacting with Web3 and Aragon should set a good example for others to follow here by building for interoperability and open standards whenever possible.


#8

Definitely agreed about open standards and interoperability - that’s why in our Flock it says that data should be:

Standardized — by content addressing data and following open data standards, we can make people’s work more compatible across DAOs and other open source projects"

It seems like both you and Luke are the pro-3box route, I am also curious to hear what @jorge and @luis’s thoughts are about 3box and anyone else that wants to chime in.

I reviewed the previous DAO Identity thread again and saw you had brought it up 3box / Ethereum Profiles there too @light. But I don’t think there was any feedback from Jorge or others from the dev side on if that will be the path that Aragon Identity takes for avatar/name/bio.


#9

3box is a profile tool built for dapps that works, but I’m brand-agnostic so long as the solution is open, decentralized, and interoperable. If there’s another profile standard that is more widely adopted I might prefer that. And if whatever that is doesn’t already use it, I would go a step further and advocate using an existing standard for profiles like the Person schema from schema.org. But I don’t want to be too prescriptive in my feedback: I am just a user who is looking for a particular user experience, am not too opinionated about existing solutions since it’s a relatively new area, so I will leave it to the devs/designers to decide what is the best tool to achieve that experience (or something close to it). Thanks for hearing me out!


#10

Loved 3box!! It offers social verification like Keybase, but it’s much lighter and Ethereum-native. Loving it. I think something like that could work


#11

This would just be an initial exploration into these cross-application user experiences. Some of the changes towards these experiences have already been done in aragon.js our goal is to work towards having a better understanding of what leveraging these changes looks like. We’ve already started to explore this in an extremely coupled way in our work on the planning suite. The big cons I think are around the additional front end development effort it might require, and the potential security implications. I’m admittedly not a UX expert, but I think if there’s a spectrum ranging from developer to luddite you’d find a pretty high correlation between that range and the range of preference between generalized and specialized. I feel strongly that the ability to create more specialized user experiences will be increasingly important as we attempt to expand the user base along this spectrum.


#12

Hey @light! Great to hear we’re on the same page about the importance of identity interoperability and avoidance of data fragmentation. This would be so much simpler if there was already a widely accepted identity standard that we could just plug and play.

Getting to that point will take time and coordination, and like you said, doesn’t seem to be Aragon’s responsibility. For now, how can we prepare to painlessly adopt stable identity standards as they emerge?

Is adopting 3Box now the best answer to that question? We don’t know yet! We’re also excited by its aim and plan to do diligence on areas like these:

  • Is 3Box stable for production? Not only is 3Box new, it’s on top of OrbitDB which says in the README: “OrbitDB is alpha-stage software. It means OrbitDB hasn’t been security audited and programming APIs and data formats can still change. We encourage you to reach out to the maintainers if you plan to use OrbitDB in mission critical systems.”
  • What would it add to dev time?
  • Has 3Box been audited?
  • What UX requirements would this add?
  • Which dapps have adopted 3Box? What’s been the feedback?
  • What open data standards are they using? Who are they coordinating with on this effort?
  • What’s their runway?
  • What promises (if any) do they make to their users?
  • What does the process of migration to 3Box look like if it gains widespread adoption?
  • What would the process of migrating off 3Box look like if it happened to go down or another standard emerges?

Don’t hesitate to help us answer these questions if you have information and let us know if other solutions seem interesting.


#13

I keep seeing 3Box everywhere and I’m just itching to have a PoC for testing it within an app. I’m open to ideas that we could build to try to answer @Schwartz10 questions.

Apart from the identity thread in Aragon Coop, is there any other place where we can discuss identity? There’s so much in there, from Civic, to even the Estonian E-Residency project. I feel this is a crucial topic and would like to have some place where we can isolate this content.