We need to run a devnet in a Docker container with WebSocket support. It should also deploy the contracts from aragon/aragon-core.

From discussions with @bpierre:

cache sounds more like an optional optimization feature, for non-persistent storage.

store (or state?) maps better to the flux / redux naming pattern, and may be more obvious for new developers coming in.

We should add another type of messaging provider in @aragon/messenger to support webworkers.

Requires aragon/aragonOS#213

We have an ABIs directory that is updated manually with the latest version of the aOS ABIs.

@izqui:

Migrating from our own GovernanceToken to a generic token standard, MiniMe, we have lost the ability to ask the contract for all the holders.

Now we need to locally cache the list of holders by listening to transfer events. All tokens of the DAO can be accessed using the TokenOrgan (https://github.com/aragon/aragon-core/blob/master/test/integration_ownership.js#L50)

Will be adding a TokenAdded and TokenRemoved at the DAO level to make it easier to listen to changes.

Moved from aragon/client#27.

Whenever a response is received in the RPC messenger (src/rpc/Messenger.js) and it is an error, then an error should be emitted on the observable as opposed to just passing it through as a normal response.

The responses and errors conform to the JSONRPC 2.0 spec.

"Native" apps like Settings and Permissions should have a way to read and modify the cache.

The wrapper may also like to store some items in the cache, such as the default account.

Related to #41.

Apps that interact with contracts outside an Aragon organization need the ability to make calls and transactions to other contracts. The most obvious example is apps that work with tokens (such as the Token Manager or Finance) which depend directly on the tokens to fetch balances. Another example is the Fundraising app, in which buyers need to interact with their tokens in order to buy in sales.

In the case of sending transactions, it should be handled differently than current 'intents' and allow to perform the action directly without calculating any fwd path. The signer in the wrapper should let the user know it is not a 'normal action' being performed and it could have consequences. In the case of known actions such as token transfers, we would be able to provide a description for it.

See guide.

Lowdb by default imports all of lodash, which we don't currently use in the frontend. Using the fp version however, lets us specify only the functions we need, which would save a lot of weight.

Notifications are sent to the wrapper in the following format:

type Notification = {
  id: string,
  appId: string,
  timestamp: number,
  title: string,
  body: string,
  context: ?any
}

The title, id and appId properties are provided by node-aragon, not the wrapper or the client.

The RPC call for the applications is as follows:

type NotificationCall = {
  id: string,
  jsonrpc: '2.0',
  method: 'notification',
  params: [number, string, ?any]
}

Where the first parameter is the UNIX timestamp of the notification, the second parameter is the notification body and the third (and optional) parameter is the notification context.

When a notification is clicked, the wrapper should perform the following steps

• Load the application instance
• If the notification has a context that is not null or undefined, then the following JSONRPC request should be sent to the application. The wrapper should not expect a response from the application.

type NotificationContextCall = {
  id: string,
  jsonrpc: '2.0',
  method: 'context',
  params: [any]
}

Where the first parameter is the context of the notification.

Both aragon-dev-cli and node-aragon interact with APM, so we should probably extract the functions as a separate library to avoid code duplication.

Since the client (for applications) is very small (1 file with 2 imports) and the wrapper is considerably bigger than the client, we should probably separate the two to reduce bundle size and separate the code in a meaningful manner.

I don't think this is top priority right now, so I've scheduled it for the next version.

My thinking is that applications would import @aragon/client or something similar and wrappers would import @aragon/wrapper.

Is there an example of using this with an Aragon contract? Ideally, an integration with something here would be very helpful.

Pre-meeting notes

Goal: Library used by Aragon UI and first- and third-party modules to interact with Aragon contracts.

Implements logic most apps will need to function.

Basic features:

• Installation of organs and apps

• Interaction with MetaOrgan

• Listen and cache events related to app and organ installation.

• Expose API for apps to listen for events (aragon.js will catch syncing state)

• APM support:

  • fetching a dependency
  • parsing the aragon package json
  • finding the factory for the application
  • deploying a new instance
  • getting meta info about already installed apps

• Generic dispatcher:

  • Show info about action (natspec)
  • Bylaws integration for default controls (vote, status, tokenholder). Beware of conditional composable bylaws!
  • plug-in for custom bylaw oracles
  • queue of pending transactions and past transactions
  • sends transaction to the signing provider on user approve

Action items

• APM will live as its own separate codebase, aragon.js will import it and use part of it.
• aragon.js responsibility ends once the transaction payload has been constructed. Signing and broadcasting is done at the correspondent signing provider.
• @onbjerg to explore with desired interface for the module.
• @izqui to add organ and application installed events to aragon-core for aragon.js to cache.

Open challenges

• Application inter-operability: When dispatching an unrelated action, aragon.js detects the action needs a voting. Voting is no longer a native action but an application specific one. To what extent aragon.js creates the voting or 'links' to the Voting app for the voting to happen.
• Application defined bylaws or bylaw oracles: Applications aren't able to define their own type of bylaws (they can use generic ones) in aragon-core right now. Custom bylaws are supported through 'oracle bylaws' in which a certain contract address is asked whether an action is permitted. How do we support this?

Readme.md links an absolute path to contributing.md but there isn't a contributing.md file in repository

https://github.com/aragon/node-aragon/blob/7cbd7ea069ca055023490d6d47edabb02baffb58/src/core/Proxy.js#L33-L37

Fetching events from block 0 is going to be a huge performance issue when run in a blockchain that has millions of blocks. The initial load should be made from initializationBlock and then cache what was the last block number in which state was stored (so in case the operation is interrupted, we know where to restart).

We should also be filtering for the specific events we need to fetch, instead of just getting all events and then filtering

App contexts give more information about a particular application instance. For example, the group application can have multiple instances, and the context for this particular app might be the app name.

The app context will be used in notifications, the signer view and the app instance selector.

Application contexts are set via. app.context(string). They can be set at any time and are optional. This will send the following RPC request to the wrapper:

type AppContextCall = {
  id: string,
  jsonrpc: '2.0',
  method: 'context',
  params: [string]
}

Where the first parameter is the app context. The client should not expect a response.

Some apps need to get events from other addresses, for example the TokenManager app doesn't emit events on token transfers because the managed token already emits them.

This should also allow to pass a filter to take advantage of indexed event logs.

This file should bundle two different components

• One for the sandboxed applications
• One for the wrapper

It should also be noted that both should be importable via. ES6 and should work in the browser, specifically the bundle for sandboxed applications should be a single file that we can inject.

We're publishing unminified code to npm, but it should probably be minified.

Should be able to configure a few things

• APM
• ...

As it stands, the cache can be arbitrarily read / set by any app, since the app decides what key to pass in. Read is not a huge deal, but modifying is.

We should sandbox the cache so that apps can only interact with their sections (e.g. prefixing the keys with the app proxy's address and not allowing cache actions across prefixes?).

If we closed off read access with this sandbox, we would additionally require a whitelisting capability. This would allow an app / wrapper to register itself as readable / writeable across different apps. A use case of this would be the Settings app, where other apps will likely need to have read access to the settings.

The function should be able to describe "vanilla" transactions and transactions with EVM callscripts, which might include EVM callscripts further down (yes, deeply nested callscripts are a thing).

Steps

• Find a way to identify transactions with callscripts to separate the two types
• For callscripts, split the callscript into individual "vanilla" transactions
• Describe each "vanilla" transaction individually

Types

type TransactionDescription = {
  description: string
}

type DescribedEthereumTransaction = EthereumTransaction & TransactionDescription

There's no reason we should manually maintain ENS-specific code if there exists a good and minimal library for it.