Profile

[Schwartz10]

No description provided.

[AquiGorka]

I've used js-ipfs-ctl to find out if there is a local ipfs daemon running, maybe check before going for infura?

[Schwartz10]

@stellarmagnet can you provide the V1 profile designs please?

Instructions for running this branch. In your terminal, first clone the repo:
git clone git@github.com:openworklabs/aragon.git

Get the development branch:
git fetch origin dev
git checkout dev

install deps:
npm i

start the app:
cd aragon
npm run start:with:profiles

Navigate to http://localhost:3000/ and create an organization on rinkeby. Once on your organization, you have to manually navigate to profiles via the url bar:

Your profile:
http://localhost:3000/#/<ENS-NAME>/profile/

Someone else's profile:
http://localhost:3000/#/<ENS-NAME>/profile/<ETHEREUM-ADDRESS>

Example:
http://localhost:3000/#/schwartzzilla.aragonid.eth/profile/0x501D456ed92F1223D71208A8e6d3F77761174AF1

next steps
As discussed with @bpierre and @AquiGorka:

(immediate)

• decide if we should make the Profile its own separate repo + node module and include it in aragon/aragon as a dependency. My vote is yes - publish as a separate package - it should make future maintenance way smoother and scales better for future native apps developed by non-A1 teams.

(not immediate)

• code cleanup with a useProfile hook (can't wait to implement this :))
• figure out how to use the app identity badge (or something similar) in the signing panel to show the aragon profile application requested a user's signature
• figure out how to remove ipfs as a dep (we're only using this to add image files to IPFS, so maybe we can ask 3box to build this functionality into their api)
• remove momentjs as a dep in favor of https://date-fns.org/
• use pixes for sizing
• match styles (like grid units, margins...etc) with native aragon designs

[Schwartz10]

decide if we should make the Profile its own separate repo + node module and include it in aragon/aragon as a dependency.

Realizing this will also depend on how we integrate with the identity provider stuff. I haven't thought too deep into how the codes would work for this yet.

[Schwartz10]

Just spoke again with @AquiGorka about strategy for including profiles in the client. We have some good ideas, but will still need opinion/confirmation from @sohkai when he's available again.

Key takeaways:

• It's best to include the profile work as some sort of external dependency. Updating and maintaining profiles as part of the Aragon client repo would require a lot of resources from A1 for code reviews.
• The profile module should be rendered in some type of iframe. The type of iframe to use is a wip - Gorka is going to look a little deeper into this issue. If no good or simple solution is found, one solid alternative is to provide a special iframe for the profile app with the allow-iframe-origin header set in the sandbox.

For now I'm going to work on publishing aragon profile as a node module

[CLAassistant]

Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
2 out of 3 committers have signed the CLA.

✅ Schwartz10
✅ rkzel
❌ chadoh
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[Schwartz10]

Hey, a quick update.

I've been wrestling with module bundlers (rollup) to try and publish a bundled version of the Profile application. Most of the trouble has been to properly compile 3box and its dependencies without adding a ton of memory usage to the Aragon client bundling process (npm run start:with:profiles). I briefly debugged this with @bpierre yesterday, and am working on addressing this with their team. Conversation here.

[Schwartz10]

Also @bpierre - some of the IPFS bundling issues we were running into yesterday, especially with large memory usage could probably be related to: ipfs/js-ipfs#1927

[bpierre]

@Schwartz10 interesting, thanks! 👀