Embed or Extend the Aragon Client

[lkngtn]

Is your feature request related to a problem? Please describe.

We want people to be able to go in and out of the Aragon Client interface without leaving Apiary. We also want to add functionality for managing subscriptions and notifications as an individual user. Some of this functionality exists within the Client (notifications, web3 auth).

Describe the solution you'd like

Ideally we would be able modularize the user focused elements of the client (web3 auth, notifications, local labels):

So that these can be provided by Apiary, and then simply embed the client without these features, to minimize compatibility/maintenance issues.

Describe alternatives you've considered
Not sure, but would totally open to other alternatives that meet the fundamental requirements.

[sohkai]

I think rather than trying to add Apiary functionality into a canonical "client", I think it would be better to make it so it's easier and more maintainable to create variations on the client that offer optimized UX for specific (and potentially divergent) user groups.

Depending on how far Apiary wants to go in its "preview" mode, I see a few choices:

1. Directly embed the Aragon client via an iframe, and use it as a completely separate app where you can only control the URL. You can mount/unmount this iframe as you like, and navigation can be done by simply changing the iframe's URL
2. Rely on @aragon/wrapper and re-write or re-use the "aragonAPI integration layer in the client". You now have full control over obtaining organization information, starting apps, and saved local labels. A1 can open our hosted notification-service's APIs to you, if you'd like to integrate.
3. We can re-architect the client, so that it has a library export similar to how databases have different "engines" (e.g. InnoDB). The default client experience shipped with mainnet.aragon.org would just wrap some UI and aragonAPI-elements around this engine, and other "frontends" could do the same. However, it is unclear how different this would be in practice from 2 and where we would want to separate.

1 is by far the easiest at the moment.

I think it's useful to maintain a canonical version of aragonAPI, but having multiple versions or variations on the "Client" itself would be beneficial. This enables multiple teams to work and explore different user flows and UX tradeoffs in parallel, without fracturing the Aragon App ecosystem.

This is already the case. We have a canonical version of aragonAPI; you can find it on npm with @aragon/wrapper and @aragon/api. You have access to all Ethereum-level information the client has access to by using @aragon/wrapper. Everything but the notification service is available, because it's not Ethereum-level information, and that is not exposed in aragonAPI.

I agree, though I am a bit concerned about the notifications implementation and the flexibility of it as a centralized component. It's not clear to me that notifications should be part of a canonical client implementation or part of the AragonSDK, because in practice they require a service that is hosted and offered by a specific vendor.

The client's integration with the notifications service can be seen as a purely "frontend" interface to it. It exposes web2 APIs; the client integrates with those APIs. Other apps can integrate with those APIs and provide their own frontends.

---

@dizzypaty

In my opinion, having a more user-centric notifications management is not “optimized UX for a particular, divergent user group” but rather an improvement that can benefit all Aragon users and that should be conceived at a higher level than a particular “client implementation” (once we start having those). That way, all the versions of the client could also benefit from it, similarly to other global elements like the account module or local storage.

I highly agree we could move various user-related information up, to where it's not just local to the client.

There are a few pieces of information I see:

• User state
  • Account: already handled externally by a web3 provider
  • Local labels: we could share this state by moving it up to a "sync server"
  • Notifications: this already exists as an external API
  • Client settings: this should exist solely in the client
• Organization state
  • Most state is either from Ethereum, or assumed to go into an IPFS blob tethered to the organization
  • More state may be held in "sync servers", from app-level information to profile or user-level customization