unilogin / unilogin Goto Github PK
View Code? Open in Web Editor NEWUniLogin Monorepo
Home Page: https://unilogin.io/
License: MIT License
UniLogin Monorepo
Home Page: https://unilogin.io/
License: MIT License
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
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:
This will require changes in React Backup
and ``BackupView components in universal-login-example
.
identityService
, which should be passed as props to Backup
from ContentContainer
.Even this feature is quite big, so could split into 2-4 PRs.
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.
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.
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.
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
It is currently somewhat complex.
constructor(bytes32 _hashLabel, string memory _name, bytes32 _node, ENS ens, FIFSRegistrar registrar, PublicResolver resolver) public {
...
}
Proposed PRS:
authorised
, onlyManagementKeyOrThisContract
, onlyManagementOrActionKeys
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:
string _ipfsAdditionalData
and string [] _ipfsAdditionalData
respectively.This gets us away from the traditional paradigm of storing user data and keeps us more decentralized.
Thoughts and comments?
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.
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.
There should be a clean hierarchy, that would map directly to HTTP codes.
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
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)
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 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:
We don't use ERC725 implementation anymore. We can now remove unused contracts and simplify KeyHolder:
adressToBytes32
conversions in all of the subprojects and use the address
type as key
Backup code doesn't work when going through Login->Connect->Recover flow, I will try fixing in #97
If you create a new login for a domain that doesn't exist, then the app keeps showing 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.
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
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:
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.
With CREATE2 we can now create counterfactually deployed wallet contracts.
I think we should split that into multiple PRs:
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
Update contract creation in relayer
Add observer in SDK
Add refund to ERC1077 constructor
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.
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
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
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
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
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 {
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.
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"
This is a high-level summary of work accomplished in milestone one of Universal Logins.
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?
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:
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.
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
Current build seems to be broken.
dev:start
loghuman@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.
...
./scripts/test.sh
fails4) 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 build command fails when executed on Windows.
Resolution is probably to integrate cross-env on the babel calls.
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.
execute
callWhen 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)
getMessageStatus
callAfter 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.
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.
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
What i did:
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"}
`
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:
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.
The database for the authorisation service should be customisable and not force postgreSQL.
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?
Identity-related naming is now deprecated. The main user-centric contract should use "wallet" or "walletContract" naming
Examples:
IdentityProxy
, IdentityMasterCopy
-> WalletProxy
, WalletMasterCopy
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:
Happy to hop on a remote pair-programming session to kick-start implementation.
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.
UniversalLoginSDK$ uname -a
Linux hostname 4.4.0-139-generic #165-Ubuntu SMP Wed Oct 24 10:58:50 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
UniversalLoginSDK$ yarn -v
1.12.3
UniversalLoginSDK$ node -v
v11.3.0
UniversalLoginSDK$ yarn
yarn install v1.12.3
[1/5] Validating package.json...
[2/5] Resolving packages...
[3/5] Fetching packages...
error https://registry.yarnpkg.com/flatmap-stream/-/flatmap-stream-0.1.2.tgz: Extracting tar content of undefined failed, the file appears to be corrupt: "Unexpected end of data"
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
check check
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.