It seems we can simplify ENSRegistrar constructor and reduce deployment price:

We can use parentNode and label (we can make it string or even bytes32), so that

• nodeHash = keccak256(keccak256(label), parentNodeHash)
• nodeName = label + reverseName(parentNodeHash)
• FIFSRegistrar registrar -> owner(parentNodeHash)
• PublicResolver resolver -> could be resolver of parentNodeHash

It is currently somewhat complex.

constructor(bytes32 _hashLabel, string memory _name, bytes32 _node, ENS ens, FIFSRegistrar registrar, PublicResolver resolver) public {
   ...
}

https://github.com/UniversalLogin/UniversalLoginSDK/blob/master/universal-login-contracts/contracts/ENSRegistered.sol

Proposed PRS:

• add performance test here
• do implement and see cost reduction in gas

In the name of security, I think it would be awesome to have keys that are limited to transferring only one type of token on an identity. This way, if a user has an identity and adds a key from this clicker example, that key can only use kilks. This way, even if a key from the clicker service becomes compromised, the other funds in the users identity are guaranteed safe.

As far as real adoption is concerned, the Relayer component has a key role in the Universal Login system.

The off-chain interface offered by the Relayer, referred as IF-6 in the system architecture diagram, could be IMHO well worth the proposal of a standard in terms of:

• the application layer format, i.e. JSON object matching ERC #1077 and #1078
• the transport layer format, i.e. Whisper protocol, HTTP protocol

This could also help the raising of multiple Relayer implementations, accessed indirectly via Whisper or directly via HTTP, which any client using the Universal Login SDK in Javascript (or another one in the language of choice) could force to compete against each other.

I would like to know if this sounds reasonable and if a PR documenting such standard interface (maybe in the Proposals repo?) would be appreciated.

I was talking with @austingriffith here at DEVCON4 and I think we should add his transaction loader to the UI (especially for mainnet when the user has no idea when transactions will go through). A little work needs to be done on the dapparatus side, but I will talk with Austin about this.

Can we have ENS contracts/jsons as external dependency?

NPMs:
@ensdomains/ens
@ensdomains/resolver

Example:
https://github.com/Amxx/KitsuneWallet-ERC1836/blob/master/package.json

Identity-related naming is now deprecated. The main user-centric contract should use "wallet" or "walletContract" naming

Examples:
IdentityProxy, IdentityMasterCopy -> WalletProxy, WalletMasterCopy

When building with quick deploy option and trying to log in:

When doing manual deploy, works normally.

A malicious gas relayer could substitute the key in an authorisation request with a key they control. Therefore a visual representation of the key (e.g. blockie) should be displayed with pending authorisations (instead of browser / OS / IP). This should also be shown when requesting to connect - so user can visually confirm they match.

In Alex's Unconf video in May one of the recovery options mentioned was centralised recovery, that users could disable/enable.

I think this will be important for onboarding users new to decentralisation.

This is a thread for anyone participating in Status #criptolife Hackaton in Prague. The best universal logins project will get a $1000 in dai (or ether)

Current build seems to be broken.

1. Errors in dev:start log

human@AllDev:~/work/UniversalLoginSDK/universal-login-example$ yarn dev:start
yarn run v1.12.3
$ babel-node scripts/dev-start.js
Starting ganache...
Ganache up and running on http://localhost:18545...
Deploying ENS contracts...
Deploying token contract...
Token contract address: 0x850437540FE07d02045f88cAe122Bc66B1BdE957
Starting relayer...
Deploying clicker contract...
Unhandled rejection Error: connect ECONNREFUSED 127.0.0.1:5432
    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1161:14)

(node:11509) UnhandledPromiseRejectionWarning: Error: connect ECONNREFUSED 127.0.0.1:5432
    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1161:14)
(node:11509) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 8)
(node:11509) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
...

2. dropdown box never finishes loading

3. ./scripts/test.sh fails

4) Relayer - Config routes
       "before all" hook:
     Error: connect ECONNREFUSED 127.0.0.1:5432
      at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1161:14)

  5) Relayer - Config routes
       "after all" hook:
     TypeError: Cannot read property 'stop' of undefined
      at _callee3$ (test/relayer/routes/config.js:26:13)
      at tryCatch (/home/human/work/EthUniLog/UniversalLoginSDK/node_modules/babel-runtime/node_modules/regenerator-runtime/runtime.js:62:40)
      at Generator.invoke [as _invoke] (/home/human/work/EthUniLog/UniversalLoginSDK/node_modules/babel-runtime/node_modules/regenerator-runtime/runtime.js:296:22)
      at Generator.prototype.(anonymous function) [as next] (/home/human/work/EthUniLog/UniversalLoginSDK/node_modules/babel-runtime/node_modules/regenerator-runtime/runtime.js:114:21)
      at step (/home/human/work/EthUniLog/UniversalLoginSDK/node_modules/babel-runtime/helpers/asyncToGenerator.js:17:30)
      at /home/human/work/EthUniLog/UniversalLoginSDK/node_modules/babel-runtime/helpers/asyncToGenerator.js:35:14
      at new Promise (<anonymous>)
      at new F (/home/human/work/EthUniLog/UniversalLoginSDK/node_modules/core-js/library/modules/_export.js:36:28)
      at Context.<anonymous> (/home/human/work/EthUniLog/UniversalLoginSDK/node_modules/babel-runtime/helpers/asyncToGenerator.js:14:12)

  6) Relayer - Identity routes
       "before all" hook:
     Error: connect ECONNREFUSED 127.0.0.1:5432
      at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1161:14)

  7) Relayer - Identity routes
       "after all" hook:
     TypeError: Cannot read property 'stop' of undefined
      at _callee6$ (test/relayer/routes/relayer.js:74:13)
      at tryCatch (/home/human/work/EthUniLog/UniversalLoginSDK/node_modules/babel-runtime/node_modules/regenerator-runtime/runtime.js:62:40)
      at Generator.invoke [as _invoke] (/home/human/work/EthUniLog/UniversalLoginSDK/node_modules/babel-runtime/node_modules/regenerator-runtime/runtime.js:296:22)
      at Generator.prototype.(anonymous function) [as next] (/home/human/work/EthUniLog/UniversalLoginSDK/node_modules/babel-runtime/node_modules/regenerator-runtime/runtime.js:114:21)
      at step (/home/human/work/EthUniLog/UniversalLoginSDK/node_modules/babel-runtime/helpers/asyncToGenerator.js:17:30)
      at /home/human/work/EthUniLog/UniversalLoginSDK/node_modules/babel-runtime/helpers/asyncToGenerator.js:35:14
      at new Promise (<anonymous>)
      at new F (/home/human/work/EthUniLog/UniversalLoginSDK/node_modules/core-js/library/modules/_export.js:36:28)
      at Context.<anonymous> (/home/human/work/EthUniLog/UniversalLoginSDK/node_modules/babel-runtime/helpers/asyncToGenerator.js:14:12)

The ERC721 standard defines both safe (safeTransferFrom) and unsafe (transferFrom) APIs for the NFT ownership transfer to a smart contract. The safe transfer API, which prevents unintentional transfers to NFT-unaware contracts, requires that the receiving contract implements the ERC721TokenReceiver interface according to the spec.

The current ERC1077 contract implementation does not support such an interface, so any ERC721 safe transfer fails.

check check

i am trying to setup a relayer on rinkeby but i need the resolvers and registrar addresses of each domain, in ENSRegistred.md there is only the public resolver address. is it possible to have the testRegistrars addresses and resolver address of each domain, and maybe add them somewhere in the docs. many thanks in advance.

Currently ‘yarn clean’ removes ‘node_modules’. Running yarn install after clean leads to uncontrolled dependency updates, which leads to nasty bugs.

We should remove node_modiles deletion from clean script.

Optionally we can make yarn purge script (which do delete node_modules) which might be useful for experimentaion and debbuging.

Currently, the private keys are stored in session storage and are lost when the app refreshes. While that's actually useful for testing purposes for fast login, we need to move all the app information to a more secure place: localstorage, localdb, cookies, maybe even in more than one place, so that the keys are hard to lose and sessions persists.

What I did:
Typed 'dteiml' into the search box.

What I expected to happen:
I get a list of options to create and id.

What happened:
It's been loading for 11 minutes:

Currently when you approve a new device to use your app, it is by default a "management key" which means that it has unlimited powers to do anything they want to the contract. The only limits on keys are given by the purpose and the requiredApprovals number set by ERC725 standard. This is insufficient.

Consider the case in which you might want to add a phone that is able to add and approve new devices on the contract, but you want to set limits on how many new keys they can add in one day to prevent abuse. Or maybe you want to be able to add access to a very limited scope, maybe a key that can only interact with a single contract. To do that we need to either replace or improve the key purpose concept with an "authorization contract" that authorizes a key to do things according to a given set of rules.

We want to keep the types of authorization contracts open, so for the purpose of this issue we would simplify with 2 example authorization contracts:

• a contract that limits which contracts that key can interact with. It can be set to no contracts, only one specific contract, or any contract
• a contract that limits the amount of "addKey" operations that each key can do, on the identity contract, per day. By default the logic would be: after adding N new keys, no new "addKeys" operations are accepted for N days

A proposed layout for how this would look for the user would be similar to the authorization screens of android or facebook apps, to be added on the "pendingAuthorization" screen:

3Box.js by uPort is a project for keeping private and public data about an account without relying on blockchain storage. It is currently under development and requires metamask, but it would be interesting to have it integrated with Universal Logins at some point.

From my understanding, it uses orbit-db which is a single key database that is kept in sync with IPFS, storing both private and public data, by using a web3 "sign message" format. In order to adapt it to Universal logins we would have one orbit-db for each private key that is added to the main account, and those private keys would have to communicate and sync their information. Since the only consequence for any failure to sync is simply having one device with outdated information, we should make the sync as painless as possible.

The private information that would be stored in the app could be information about the keys (which machines they are, where that device was last seen, if a key belongs to a paper backup or not, etc), while the public information could be made to create a profile with basic information like a name and picture, or an IPFS file with a series of text/tweets posted.

priority: nice to have, something to work on in the future

One of the main drawbacks of the contract as your account is that it creates a fixed cost for user acquisition. This can be improved by "counterfactual deployment" or, a method in which you can deterministically sign a transaction in which you are certain of what will be your final address, in a way that it can be deployed by anyone later. It has the following advantages:

1. The user knows their address immediately and doesn't have to wait for a transaction to be mined
2. The same address can be generated on all networks, including private or test networks, so the app can onboard users on a cheaper network (or a side chain) and then migrate them to the main chain only when required
3. The address can refund the deployer and therefore only deploy once the address has funds to pay back
4. almost as a side effect, it also allows the user to select their icon and address from multiple generated ones.

How would this affect this app

The user interface would be changed very little by this, as it's mostly something that happens under the hood. One interesting thing that could be done would be to add one screen to the "create account" view in which allowed the user to pick an icon from a list of 16 generated ones.

With CREATE2 we can now create counterfactually deployed wallet contracts.

I think we should split that into multiple PRs:

1. Add CREATE2 contract factory with support for meta transactions.
   Intial implementation of factory by @cwhinfrey is on ETHDenver hackathon branch.
   Also related open-zepplein issue

2. Update contract creation in relayer

3. Add observer in SDK

4. Add refund to ERC1077 constructor

This is a high-level summary of work accomplished in milestone one of Universal Logins.

The purpose of the Github issue is to:

• document the work done for this bounty
• serve as a Github issue that will be used by the Gitcoin smart contract

Summary

• Implementation of ERC1077 (Executable signed message) and 1078 (Universal Logins)
• Working smart contracts that register ENS subdomains and create an ERC721 identity
• Open source front-end interface in html/js
• Example app boilerplate
• Open source node-js relayer server
• All code meant to be basis of other projects
• Documentation, tutorial and developer package

Relayer API for multisignature transactions

With the introduction of multisig into Universal Login the transaction is not immediately sent to the blockchain after the call to execute.

To remedy this I propose that the transaction lifecycle is acknowledged on the relayer side and made accessible through its api.

The execute call

When a transaction is to be made using UniversalLogin it is composed into a message object. This message object looks something like this:

const message = {
  from: 'universal_login_contract_address',
  to: 'recipient_address',
  data: '0x00',
  value: 0,
  ...moreStuff,
}

When Alice and Bob are both parties in the 2 of 2 multisig they have to both submit the same message to the relayer with different signatures.

Alice:
relayer.execute(message, alices_signature)

Bob:
relayer.execute(message, bobs_signature)

The getMessageStatus call

After Alice calls execute she would like to be able to know when Bob submits his signature of the message. In order to do so she polls the relayer:

relayer.getMessageStatus(hash(message)) -> COLLECTING_SIGNATURES (1 of 2, message)
relayer.getMessageStatus(hash(message)) -> COLLECTING_SIGNATURES (2 of 2, message)
relayer.getMessageStatus(hash(message)) -> PENDING_ON_CHAIN (0x1234...5678, message)
relayer.getMessageStatus(hash(message)) -> MINED_ON_CHAIN (0x1234...5678, message)

The getMessageStatus call returns a stage of the transaction lifecycle the transaction is in.

Transaction Lifecycle:

Non-error states:

UNKNOWN
COLLECTING_SIGNATURES (1 of N, message)
COLLECTING_SIGNATURES (2 of N, message)
...
COLLECTING_SIGNATURES (N of N, message)
WAITING_FOR_SUBMIT (message)
PENDING_ON_CHAIN (txHash, message)
MINED_ON_CHAIN (txHash, message)

Error states:

ERROR (message)

Transaction moves down through non-error states until reaching MINED_ON_CHAIN. If at any point an error happens it transitions to the ERROR state. The transaction can move through multiple states at once.

Ommisions

This issue does not concern itself with the method of sharing the message between participants of the multisig. This can probably be achieved via another mechanism.

The build command fails when executed on Windows.

Resolution is probably to integrate cross-env on the babel calls.

We don't use ERC725 implementation anymore. We can now remove unused contracts and simplify KeyHolder:

• rename ERC725KeyHolder to KeyHolder
• remove keyType
• remove adressToBytes32 conversions in all of the subprojects and use the address type as key

https://github.com/UniversalLogin/UniversalLoginSDK/blob/master/universal-login-contracts/contracts/ERC725KeyHolder.sol

We would like to implement the Backup Keys functionality in the example application.

Functionality is mocked in the application already.
To get there one needs to login/create identity than click Account -> Backup code -> "GENERATE NEW CODE".

The feature is pretty big, and therefore I would propose to split it into multiple PR:

1. UI and backup phrase generation

This will require changes in React Backup and ``BackupView components in universal-login-example.

• Generate and display three backup codes when screen shows-up
• Display actually Identity info (should be taken from identityService, which should be passed as props to Backup from ContentContainer.
• Implements 'generate 3 more codes' button
• Use Daefen

Even this feature is quite big, so could split into 2-4 PRs.

2. Implement adding multiple keys in smart contracts

That will require adding a similar method to

function addKey(bytes32 _key, uint256 _purpose, uint256 _type)

I propose the following format:

function addKeys(bytes32 [] _key, uint256 [] _purpose, uint256 [] _type)

Function would simply iterate ove arguments and call addKey.

3. Implement functionality in SDK and connection it all together in Example

I run localhost:1234 on 2 browser clients in same machine. On one I create a user id, in other I try to login with the user id created in the first browser. I get pending authentication notification in the first browser - but I am not able to accept authentication. Attached is the browser console log

After the user has his connection approved, and after they have recovered from backup, they should be redirected to greeting view.

The greetings View should also reflect the current state of token granted: instead of saying "you'll get x tokens for doing N" it should say "you did N and got x tokens for it"

Issue: Hello, I have an issue in reaching you @marekkirejczyk

Jk. Lol. I hope you don't mind this extremely intrusive and out of place github issue but I couldn't reach you anywhere else.

Alex van de sande raised an excellent suggestion of having you lead our next meta-tx community call around the contract abi standardisation

We have got a few more teams uploading their code: https://github.com/Meta-tx/Harbour-MVP/tree/master/DEMOS

We were thinking of doing this meeting this tuesday on the 16th however if that is too short of a notice, lets do it thursday / friday?

Cheers,
Peter

Hey @marekkirejczyk and @JustynaBroniszewska!

Currently I am focusing on a fork of this project full time. I would like to contribute back to the parent repo as much as possible, but I'm not sure what you guys are working on. If we could set up a quick community call to set up a task board or something similar then I could help you guys speed up progress towards your demo at Devcon4.

Cheers,
Kyle

To demonstrate Universal Login functionality we created Universal Wallet project here.

To showcase and testing how simple onboarding could be we would like to integrate simple debit card flow with Wyre.

The HTML and CSS are ready and sliced:

• https://github.com/UniversalLogin/UniversalLoginSDK/blob/master/universal-login-wallet/src/ui/Modals/ModalPersonalInfo.tsx
• https://github.com/UniversalLogin/UniversalLoginSDK/blob/master/universal-login-wallet/src/ui/Modals/ModalCardInfo.tsx

Happy to hop on a remote pair-programming session to kick-start implementation.

Generate backup codes should save the new code, as currently not obvious to a user that the backup code generated needs to be saved.

Currently the flow is:

1. Go to Account page
2. Press Backup code button
3. Press Generate New Codes
4. A new code is generated, with instructions to print
5. A user prints the backup code
6. A user needs to press the Set as Backup Codes button before it can be used.

It is not obvious to a user that the backup code hasn't been saved so the last step could be skipped. A user could potentially print out the code without actually saving the code. To close the window, they could press Cancel backup code.

Ideally with the Generate New Codes and Generate Another Code there would be a message stating this would cost 2 clicks and this would generate and save the code to avoid users generating, printing a code without saving it.

Hi Everyone

I tried to run the example

https://universal-login-example.netlify.com/

But it seems it is not working. I have We are creating your new ID, please wait a minute...

Forever..

Thank you!

Antoine

Hi all,

I've watched a couple of talks by @alexvandesande about Universal Login and I'm really interested in the project which looks great.

I've forked and launched the quick example obtaining a strange behavior, which seems an error, when using multiple devices. After activating the example using yarn dev:start on my desktop machine, I can create new identity from a local browser but cannot create or connect from a remote browser (e.g. smartphone or laptop): when typing the username no suggestion is proposed and I see the following errors in the browser console:

I've added an optional command line argument to dev-start.js script, specifying the HTTP address to use in Ganache and Relayer service URLs and passing one of the host interfaces it works. It's a simple solution but maybe it could be acceptable for the development example.

If this approach sounds good to you, I can submit a small PR with such changes, also describing the optional parameter in the tutorial.

Tullio

I followed the instructions in the README but stuck at the Identity creation page.. How can I see if the transaction is actually relayed to the Ganache instance or not?

• new folder structure: ENS, ERC1077, Wallet, common, mock
• extract storage contracts (as base for MasterCopy and Proxy)
• try to run tests for proxy and master as one suite with two configuration options
• simplify master and proxy implementations
• do we need both 1077 and identity master and proxy?
• merge/remove unnecessary modifiers: authorised, onlyManagementKeyOrThisContract, onlyManagementOrActionKeys
• move erc721 receiver to wallet

If you create a new login for a domain that doesn't exist, then the app keeps showing Creating ID page.

1. In the login, type bob.notexists.eth
2. Press the create button to create login bob.notexists.eth
3. App shows Creating ID page

Ideally creating a new login for a domain that doesn't exist should fail nicely with some sort of message that login notexists.eth doesn't exist or couldn't be found.

There should be a clean hierarchy, that would map directly to HTTP codes.

Backup code doesn't work when going through Login->Connect->Recover flow, I will try fixing in #97

I installed the SDK in my node test environment

npm install universal-login-sdk --save-dev

When I try to import the sdk I get an error:

Cannot find module 'babel-runtime/regenerator'

I installed babel-runtime with npm uninstall babel-runtime --save-dev but then I get another error:

xxxxxxxxxx/node_modules/universal-login-contracts/lib/calculateMessageSignature.js:1
(function (exports, require, module, __filename, __dirname) { import {utils, Wallet} from 'ethers';
                                                                     ^
SyntaxError: Unexpected token {

It would be very useful for hackatons and other similar spaces if there was an easy yarn build option that would use a test network (Rinkeby?) and infura for the connections. In this manner, multiple projects could collaborate, use each other logins, and have a real "multi user" experience.

priority: low, nice to have

What i did:

1. Input a name following the example given in the ui, like:
   yo.workthistime.eth
   (tried several others later)
2. Click on "create"

What I expected to happen
The identity to be created and the demo to proceed.

What happened
See next screen for a fraction of a second, then:

Failed to load resource: the server responded with a status of 404 () universal-login-relayer.herokuapp.com/identity:1 Failed to load resource: the server responded with a status of 500 (Internal Server Error) rinkeby.infura.io/:1 Failed to load resource: net::ERR_NETWORK_CHANGED ethers.min.js:1 Uncaught (in promise) Error: invalid response - 0 at XMLHttpRequest.a.onreadystatechange (ethers.min.js:1) universal-login-relayer.herokuapp.com/identity:1 Failed to load resource: the server responded with a status of 500 (Internal Server Error)

`
Request
curl 'https://universal-login-relayer.herokuapp.com/identity' -H 'Referer: https://example.universallogin.io/' -H 'Origin: https://example.universallogin.io' -H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36' -H 'Content-Type: application/json; charset=utf-8' --data-binary '{"managementKey":"0x0948C0a8E2372a67260CAEd307c5C842BbFdf4FA","ensName":"yo.workthistime.eth"}' --compressed

Response:
500
{"error":"Error: domain not existing / not universal ID compatible"}
`

Since we want to be storing and displaying information about the users devices - (Browser, Operating System, Location) - we need to either create a centralized data store which maps public keys to information about users devices OR I propose we:

1. Overload AddKey and AddKeys to include string _ipfsAdditionalData and string [] _ipfsAdditionalData respectively.
2. Store json blob about device, push it to an ipfs node, and then use this to display info to the user.

This gets us away from the traditional paradigm of storing user data and keeps us more decentralized.

Thoughts and comments?

The queue of pending authorisations should rather be stored on chain - in the identity contract - and not in the relayer. I envisage relayers just providing gas relay service - not storing state.
Has there been consideration for extending ERC725 to include request/authorise key functionality?

With web browser based storage we do not have the ability to save identity credentials between DAPPs. This seems like a big limitation because it would become costly and cumbersome for a user to add credential keys for every DAPP website they visit. Perhaps we should consider creating a browser plugin that can store and deliver the credentials to a DAPP?

I recently watched @alexvandesande's talk on universal logins and I'm super excited about this project! I went to check out the example app and noticed an error and wanted to bring it to your attention.

After creating an ID the loader spins perpetually. I'm seeing this in the console

POST https://universal-login-relayer.herokuapp.com/identity 500 (Internal Server Error)
asyncToGenerator.js:20 Uncaught (in promise) SyntaxError: Unexpected token < in JSON at position 0

The database for the authorisation service should be customisable and not force postgreSQL.