The layer between aragonOS, the Aragon client and Aragon apps. Use it to build your own Aragon app.
Package | Version | Downloads |
---|---|---|
@aragon/api |
|
|
@aragon/api-react |
|
|
@aragon/rpc-messenger |
|
|
@aragon/wrapper |
|
|
(Aragon 1) A monorepo of JavaScript libraries for interacting with Aragon
Home Page: https://aragon.org
License: GNU Affero General Public License v3.0
The layer between aragonOS, the Aragon client and Aragon apps. Use it to build your own Aragon app.
Package | Version | Downloads |
---|---|---|
@aragon/api |
|
|
@aragon/api-react |
|
|
@aragon/rpc-messenger |
|
|
@aragon/wrapper |
|
|
We need to run a devnet in a Docker container with WebSocket support. It should also deploy the contracts from aragon/aragon-core.
flattenTransactionPath(path: Array<EthereumTransaction>) => EthereumTransaction
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.
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
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.
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:
Generic dispatcher:
aragon.js
responsibility ends once the transaction payload has been constructed. Signing and broadcasting is done at the correspondent signing provider.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.Readme.md links an absolute path to contributing.md but there isn't a contributing.md file in repository
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.
getTransactionPath(address: string, sig: string) => Array<EthereumTransaction>
This file should bundle two different components
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
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
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.