urbit/bridge

An application for interacting with Azimuth.

Urbit

Urbit is a personal server stack built from scratch. It has an identity layer (Azimuth), virtual machine (Vere), and operating system (Arvo).

A running Urbit "ship" is designed to operate with other ships peer-to-peer. Urbit is a general-purpose, peer-to-peer computer and network.

This repository contains the Arvo Kernel

For the Runtime, see Vere. For more on the identity layer, see Azimuth. To manage your Urbit identity, use Bridge.

Install

To install and run Urbit, please follow the instructions at urbit.org/getting-started. You'll be on the live network in a few minutes.

Contributing

Contributions of any form are more than welcome! Please take a look at our contributing guidelines for details on our git practices, coding styles, and how we manage issues.

You might also be interested in joining the urbit-dev mailing list.

Release

For details about our release process, see the maintainers guidelines

bridge's Issues

Handle errors in constructors

A lot of Maybe values are examined a number of times, unnecessarily. It would usually suffice to examine stuff that we potentially could throw on, e.g. usually pointCursor, contracts, etc. in the constructor itself, rather than in the render method and elsewhere.

getting a 404 on use of bridge

I tried to use bridge, but got 404ed:

~/Downloads/bridge-1.1.0$ python3.7 -m http.server 5000 --bind 127.0.0.1 --directory build
Serving HTTP on 127.0.0.1 port 5000 (http://127.0.0.1:5000/) ...
127.0.0.1 - - [02/Feb/2019 22:36:48] code 404, message File not found
127.0.0.1 - - [02/Feb/2019 22:36:48] "GET / HTTP/1.1" 404 -

Successful transaction page back button should be contextual

ie, should return the user to the main page or the ship page depending on how the user got there.

• createGalaxy: main page
• spawnShip/setKeys etc: ship page

Necessity of "confirm availability" is potentially confusing, and shouldn't be a user action anyway

The order of operations/elements here made it take me a good couple seconds to realize I had to "confirm availability" before being able to check the "I'm sure" checkbox. The problem here is that there's already a usable element below the "confirm availability" button, so an eager/"I already know" user will quickly move on to that, and then find a dead end below it.

I don't think there's a reason to have the user manually press "confirm availability", Bridge can totally just do that in the background, right?

Going back is odd/unintuitive

Copying this directly from the twitter thread I started –

it feels kinda awkward that the back button/back gesture in the browser takes you away from bridge – I think this stems from the fact that bridge's UI takes up the entire page and therefore sends the message that each view is in fact a separate browser page

The only way to go back (during setup at least) is to click on the path at the top which isn’t totally unintuitive; but it isn’t the first thing most people would try — the thing they try leads to them leaving bridge then returning all the way back to the start screen

The most obvious way would be a back button next to the continue button imo – much easier to notice

Node selection is too limited

If I run my own mainnet Ethereum node, I currently have no way of hooking Bridge up to it. There should be a "custom" option. It's probably best to transform the "local node" option into this, since it's not uncommon to want to use a non-default port for that anyway. We can just pre-fill the custom node address field with the current local node value.

Additionally, I currently have no way of knowing where "main network" and "ropsten" point. Whose nodes are those? What are their addresses? People may find this important to know.

Documentation and instructions unclear

https://urbit.org/docs/getting-started/ says:

Click the link that says Set Urbit networking keys. Bridge will let you either download a keyfile derived from your networking keys are you can paste in your own network seed and derive a new keyfile. See our HD Wallet Spec for more information.

http://localhost:5000/ says:

Please enter a network seed for generating and setting your public network authentication and encryption keys. Your network seed must be a 32-byte-long hexadecimal string.

If you've authenticated with a master ticket or management proxy mnemonic, a seed will be generated for you automatically.

In both cases it is unclear what is the network seed. No seed was generated for me in the UI. Am I supposed to randomly generate one? Or does it have to be a specific one?

There should be more instructions and explanation or something.

Request: display LinearStarRelease information within Bridge

Addresses who own points that are locked by the LinearStarRelease contract should see the time remaining and other info from the LinearStarRelease batch() function on their main Points page, and possibly also on the individual point pages as applicable.

It's non-obvious info to new users but also very relevant, and shouldn't be overly difficult to surface.

I'm willing to take a crack at this if it's considered a good idea and there's some consensus about where it should be displayed.

Consider removing 'set transfer proxy' action from Point view

(Original title: Setting a transfer proxy asks the user to to accept an incoming transfer of a ship.)

Not sure if this is intended behavior, but it caught me by surprise and surprises are bad in Bridge.

Dropdown item spacing is off

Generate networking seed for stars from master ticket

This way, user doesn't have to remember their 32 byte network seed, but can just rely on their master ticket.

Need to be able to signal breaches while setting networking keys

When you set new networking keys, there's an argument called "discontinuous", which should be set if you're creating a new pier, so all your old connection state is gone. Currently, we default this to false, but we should add a checkbox for it.

Arguably, we should default it to true since most of the time if someone's changing their keys it's because they're breaching their ship. Counter-argument is that a breach is irreversible, while if you forget to set it you can just cycle the keys again with it set.

Not sure what's the best description for the checkbox that isn't Urbit-specific, but I suggest the following text:

• This is a discontinuous breach. This should be set if you're going to clear network state.

Mandatory fields too aggressive

I think all fields are always mandatory, aside from the passphrase for the keyfile? And I can't press continue without properly filling it anyway. Having the orange shout-y thing come up whenever I click away from a field (to select something to copy-paste in, for example) is redundant with that, and not a great experience.

User should be able to specify network in offline mode

Using mnemonic from urbit hd wallet fails to auto generate networking seed

While using the urbit hd wallet master ticket will auto generate a networking seed, using the provided bip39 mnemonic on the paper wallet will not auto generate a networking seed.

README should direct users to the releases page

A visitor to this repo might think they need to build the software from source in order to use it. A short note that releases are available could help avoid this.

"No points" displayed while they're still loading in

On slightly slower connections/machines, the "your points" section says you have no points, then a half-second later displays the points you actually own. It should put placeholder "Loading..." text there while it has a request ongoing, and then only put "no points" if that comes up blank.

Allow users to use 512-bit network seeds

for its two distinct 256-bit (32-byte) keys, but we're taking 256-bit (32 byte) manually entered seeds to generate both here, weakening the keyspace

i think it's still safe at that entropy level, so not a security issue. it's been a while and i'm out of touch, though, so take everything i say with a grain of salt

Please consider a less restrictive license.

The EULA is extremely onerous.

`Unhandled promise rejection TypeError: "private key should be a Buffer"`

Unhandled promise rejection TypeError: "private key should be a Buffer"
	isBuffer http://localhost:5000/static/js/1.414deaad.chunk.js:1:2270373
	sign http://localhost:5000/static/js/1.414deaad.chunk.js:1:2268511
	ecsign http://localhost:5000/static/js/1.414deaad.chunk.js:1:1445466
(there's more)

The browser is Firefox

Can't click my point-name to go back to that part of bridge

The ~lodleb-ritrul part of this header-bar is not clickable. It looks like a hyperlink, but is not. The cursor doesn't even change into the Mickey-Mouse hand that it normally does when hovering over a clickable link. This is annoying, because I need to go back another step to Points whenever I want to do anything else.

https://imgur.com/a/e6XYRjR

HD Path Derivation Confusion

I wanted to check to make sure that mycrypto would derive the same paths as bridge. I am finding that they are not. I am able to derive the same public key, but only when I use a depth of 1 less on Bridge compared to mycrypto. I also believe that Ethereum uses a depth of 4, the default shown is a depth of 5.

I don't want to post my public keys, so I will explain how to recreate.

• Go to https://mycrypto.com
• Attach a ledger device
• Let it derive keys from m/44'/60'/0'
• View first key, take note of it, it corresponds to m/44'/60'/0'
• Go to bridge, attach ledger device
• Use path m/44'/60'/0'
• Press Authenticate, take note of the key at the top of the page (its different for me)
• Now use path m/44'/60'/0'/0
• Now the key matches the one derived by mycrypto at m/44'/60'/0'

Can you recreate this or am I doing something wrong?

Visual sigil bug when authenticating w/ticket

Wallet Generator integration

Should be able to generate Urbit HD Wallet in Bridge easily. Some options (not exhaustive):

• New WG experience: Bridge has a new WG flow hosted where registration TGR not required (can just input a ship name) or directs user to download WG from GH release page where WG is modified to not require TGR
• Direct to old WG: Bridge has flow to generate a registration-style TGR then directs user to download WG from GH release page

Custom hardware wallet derivation path

So people can access their different children wallets under one hardware wallet

Generated transactions throw an "invalid sender" error

Trying to set networking keys for ~maldeb-hapben. I'm using the management proxy, which is a Ledger, if that's important. According to Bridge, the chainId is 1 in the transaction; disassembling the raw tx seems to suggest the chainId is 28 (!).

Instructions should be distributed with the release

The release folder does not contain instructions for running the software. It's another thing to keep updated, but seems advisable!

`hdpath = undefined` in `src/lib/trezor.js` in v1.0.1

After I hacked the source and used the default, and recompiled, it worked. In the UI I was using the default path.

No integration with browser history

I get that this might be a pain to get in, depending on how things are set up, but here's an issue for it anyway:

Pressing back in the browser takes me out of Bridge, rather than to the previous screen. Pressing forward then does bring me back, but to some screen I visited sometime, not necessarily the one I was looking at when I hit back. This feels very painful.

No optional passphrase field for mnemonic login

There are cases where users have a mnemonic wallet that's additionally secured with a passphrase. keygen-js supports this, we just need to get the input fields in.

Unable to "Set Urbit networking keys"

I just installed the newest release (1.1.0) of Bridge. Upon accessing my ship for the first time, I am told that "Before you can issue child points or generate your Arvo keyfile, you need to set your Urbit networking keys." However, the link to "Set Urbit networking keys" is greyed out and unclickable. What should I do?

Thanks!

Should support keyfiles

We should support importing keyfiles. They're extremely common in practice, and they're the default for MyEtherWallet, geth, parity, and others.

They need a password to unlock. keythereum has code you can look at to see how to process them.

"Urbit networking keys"

This cannot stand. Urbit is a forbidden word in Bridge. Get it out.

Pressing enter on "View a Point" page throws back to previous page

In below gif I first view a point by clicking the Continue button, which is the expected flow; then I try to view a point by just pressing enter, which throws me back to previous page.

No feedback after sending transaction for network keys

when you click the send transaction button it doesn't do anything until the transaction is complete.

Rekeying networking keys

We need to have a clear flow for allowing people who authenticate using the Urbit HD wallet to derive the next index networking seed in the case of compromised keyfile.

Currently Urbit HD wallet users are expected to re-key using a random 32 byte hexadecimal string as opposed to having the Bridge tool derive the next networking seed (which is one of the benefits of using the HD wallet).

Add proptypes and tests for Bridge

This will improve our release cycle efficiency.

Latest Release Installation Error

The installation guide says to run python3 -m http.server 5000 --bind 127.0.0.1 --directory build

However, when I run this I get an error (on ubuntu 16.04):

usage: server.py [-h] [--cgi] [--bind ADDRESS] [port] server.py: error: unrecognized arguments: --directory build
If I first cd to build and then run python3 -m http.server 5000 --bind 127.0.0.1 everything works properly

Add 'View a Point' button to landing page

I.e., to look up a point's public information (keys/metadata) without needing to authenticate.

This is actually sort of screwy because it sidesteps network selection. I suppose we can simply default to mainnet for this option, but it still feels a little weird.

Unrecognized arguments

The instructions in release tell me to run: python3 -m http.server 5000 --bind 127.0.0.1 --directory build

I get:

server.py: error: unrecognized arguments: --directory build

Trouble using HTTPS with localhost

Hi, I am having trouble connecting my ledger nano to bridge. I have followed the instructions and made both localhost files and then run python bridge-https.py, but the authenticate button is not working. Help is much appreciated. Thanks.

On "Your Points", sigils and point names aren't clickable

There's no reason I shouldn't be able to click anywhere on the sigil or name to achieve the same effect as clicking on "details".

Move unauthed "view a point" before wallet authentication somewhere

I'm using it to look at sigils but it's annoying to have to put in a fake mnemonic

Only accept incoming connections from localhost

When I followed the directions, it opened up the bridge UI to everyone on my network. Probably it should only listen on 127.0.0.1 rather than on 0.0.0.0.

Checkboxes can't be un/checked by clicking their labels

The text next to them should be in <label>s and properly associated, the browser will take care of the rest.

It should not be possible to attempt to spawn a planet from a galaxy

Right now if you choose to spawn a planet with a galaxy parent, the Bridge tool will allow you to sign the transaction and send it.

Example:
Galaxy ~zod is 0x0.
Planet ~dapnep-ronmyl is 0x10000.
Ecliptic.getPrefix(~dapnep-ronmyl) will returns 0x0, or ~zod.
~zod is the parent of ~dapnep-ronmyl.

If you owned ~zod, you could use Bridge and attempt to spawn ~dapnep-ronmyl.
However a check in the ecliptic.spawn() function will always make this fail when it executes and you'll just waste gas. Apparently these planets are reserved/unavailable.

Bridge should not allow this transaction to be signed and sent.

Non-existent instructions for resetting keys with Urbit Master Ticket

So, if you have a paper wallet from the Wallet Generator, you are given two pieces of gobbledygook: the Master Ticket and the BIP39 Mnemonic. Bridge software gives users the option of using either of these things things.

Cool! To the user, this just looks like there's two different "passwords" to access their point with. They come to an identical interface with either of these things.

However, there is a problem when the user needs to rekey. Them using BIP39 vs the Master Ticket results in subtle but important differences. With BIP39, "Set Urbit networking keys" presents an empty field with something about entering a 32-bit hexademical string; with Master Ticket, something is there for you, and it's not clear where it came from (it came from the HD wallet derivation scheme, but they don't know that). There's a blurb about a seed being generated for you with the second method, but you only see that once you've already logged in. The illusion of you accessing an identical user-world otherwise persists.

Ok, that's only kind of weird and annoying on its own. But in the Master Ticket Otherworld, you can modify the network seed in the "Set Urbit networking keys" area. But, despite being allowed to do that, any modification from that pre-generated string results turns out to be illegal once you try to generate an Arvo keyfile. It says: "WARNING: derived key doesn't match Azimuth keys!"

TL;DR: Why should users be able to set their own networking seed in the Master Ticket option?

Putting in an address with invalid checksum crashes the app

You can reproduce this by copy-pasting your logged-in-as address into an address field, and then changing one of the letters to/from capital.

`npm run release` does not work without some additional packages installed

npm install azimuth-solidity
npm install sigil-js

I'm guessing they have to added to package.json?

Chris's Field Report

tldr; I wrote down stream-of-consciousness thoughts as I used bridge for the first time, with no crypto experience & only marginal understanding of various Azimuth tickets/wallets/seeds/keys.

Only big issue seem to be I can't seem to do anything with my star keys (which are maybe disabled on purpose?). Other than that, this process is incredibly smooth, and the rest of the notes are all relatively minor; really great work everyone.

===

Task 1: I have an urbit planet (~ridhec-salput) wallet-generator'd PDF that I want to instantiate a pier on my computer with to connect to the Urbit network.

• First page I see is "Create A Galaxy".

  • I don't have a galaxy!
  • I was able to click "Bridge" from the breadcrumb and start from there, though, so not too bad.

• "Select Network".

  • I have no idea what these various nodes are. I just clicked "Main Network" but I feel uncomfortable about it.

• Mostly at this point, I'm worried that if I click any button, I'm creating Eternal Ramifications for my property for having not understood everything correctly. It seems like there's no actual ramifications until I select an "action" after my wallet is loaded, so maybe something to the effect of "feel free to click around, it's hard to hurt yourself until you click an Action"

• Speaking of Eternal Ramifications; I'm connected to the internet when I load bridge; am I also "loading" my "private key" in any sense? Why does wallet-generator have to be offline, but bridge is fine online?

• I'm on "Open a Wallet" now.

  • Again, I don't know what these options are.
  • I notice that I have 2 pdfs generated from the wallet-generator process; on the PDF labeled "master ticket", I have both a "master ticket" and a "bip32 mneumonic".
  • At this point in the process, I know neither which PDF I want in order to instantiate a ship, nor which property in the PDF I want to select for this option.
  • After playing around with it for a minute, it looks like which key you enter unlocks different actions when you reach the point detail page. So I figured it out eventually.

• I'm on the "point detail" page for ~ridhec-salput

  • I want to "instantiate a pier on my computer", but the only option I see here is "Generate Urbit keyfile". I'm guessing this has to be the action. This gives me a private key. Presumably there's some urbit/urbit incantation that consumes this private key to give me a pier, if that's on new-urbit.org, that's fine.

Task 2: I have an urbit star (~nosdef) that I want to spawn a planet with (~unknown).
- I'm assuming I use my "spawn seed":
- After entering my spawn seed pneumonic, the "Points" page displays:
Your Points
no points to display
- If I click "view a point", and enter in ~nosdef, it occasionally seems to error out and redirect me to the "Create a galaxy" page
- After trying a couple of times, I can view the ~nosdef "point detail" page, but no actions are available.
- Trying again with my "master ticket":
- I notice on my Master Ticket pdf that I have two @p master tickets:
~xxxxxx-xxxxxx-xxxxxx-xxxxxx
~xxxxxx-xxxxxx-xxxxxx-xxxxxx
- I'm not sure which one to use, so I tried the first one:
- Again, same problem with "spawn seed". The Your Points section prints "no points to display"
- Trying again with the second one:
- Again, same problem. The Your Points section prints "no points to display"
- Trying again with bip32 mneumonic:
- Again, same problem. The Your Points section prints "no points to display"
- I'm thinking there might be an issue with having 2 bridge tabs open, or some state that hasn't been hooked up properly. So I'll restart the server and clear the browser cache.
- Restarted server. Same issues above, no matter which key pneumonic/ticket I try.
- Ah, I figured it out! I was on "Local Node" the whole time.
- Well, I'll leave the above as a stream-of-consciousness report when you click a wrong thing. Not sure if there's any action to take here.
- Okay, so I loaded my "spawn seed" pneumonic, and every action is greyed out.
- "Spawn Proxy" matches up to "Spawn Address" in my PDF, so I believe this is a valid wallet.
- I would have expected this to unblock the "Issue Child" action.
- It does say "Points you can spawn on behalf of" on the "points index" page.
- Trying again with "master ticket" mneumonic.
- Seems to log me in, but I can't issue children, only set other keys. Makes sense.
- Trying again with "management seed" mneumonic.
- Only gives me "Set networking keys" action.
- Seems overall like I can't figure out how to take any action on my star except "Set networking keys", and "Set proxy" w/ master ticket. Giving up for now.

===