Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

having to match currencies when peering is a bad admin experience #466

Open
michielbdejong opened this issue Aug 14, 2017 · 2 comments
Open

Comments

@michielbdejong
Copy link
Contributor

When two ilp-kits peer, they have to agree on a trustline balance. This is an inconvenience which is currently solve manually by the two admins. We need to find an automated way to do this instead.

For instance, if we introduce peering request notifications, then the first admin to peer can choose the currency. Or even if not, one peer can send a hello message (see #92), and propose a currency in there for the other peer to accept.

Another option is if admin1 peers with admin2 by first opening a user account at ilp-kit2, and then using those credentials to set up the peering (that's the flow I'm using for testnet1).

@emschwartz
Copy link
Contributor

Another option is if admin1 peers with admin2 by first opening a user account at ilp-kit2, and then using those credentials to set up the peering (that's the flow I'm using for testnet1).

This was what we had before and it was a really awful experience because you needed to edit the CONNECTOR_LEDGERS config JSON object in the env.list file

@michielbdejong
Copy link
Contributor Author

I don't think one implies the other? We could have a UI where an admin can select from which users they accept route broadcasts; those users are thereby promoted to peers. This would be in the database, not in the config (obviously this would be quite a refactor because we would have to merge our users table and peers database).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants