what you support atm is self-hosting
kargakis @kargakis nitpicking
This is me reaching out :)
Is there an API documented somewhere?
And welcome! We’re delighted to help :)
see here @DavidBurkett for integration instructions: https://github.com/vault713/grinbox/blob/master/docs/integration.md
Yep, will do that
Hmm, what do you do about spam protection? If the slates are encrypted, I could just use that as a e.g. messaging service. Or am I missing something?
@jaspervdm @ravidio @lehnberg Finally ready to start writing code. The only major thing missing from the integration doc is the encrypting/decrypting slates section. Can someone give me a quick informal spec of what’s needed there, so I don’t have to dig through the code? I will if I have to, but I’m barely smart enough to read my own code, let alone someone else’s :grinning:
Also, I have a few simple questions:
- Are the keys used in the grinbox addresses just the BIPXY(32, I think?) ones generated using your seed and a keychain path?
2 Is the first challenge sent immediately upon establishing a socket connection with the server, or does the client need to initiate a handshake?
4 Can a client subscribe/listen to multiple addresses?
5 Is the JSON plaintext, or is some kind of socket-layer encryption used?
And last, but not least:
6 Wen moon?
@DavidBurkett
- Yes we use a modified BIP32 hasher - see https://github.com/vault713/wallet713/blob/master/src/common/hasher.rs#L74
- Yes, challenge is sent immediately after establishing the websocket connection.
- Challenge was initially used for signing the slate so we wanted to have a shared challenge between all users, however it’s not used like that anymore, and only relevant when subscribing, so indeed we might switch to session based in the future
- No, not at the moment
- JSON is a plaintext
EncryptedMessagehttps://github.com/vault713/wallet713/blob/master/src/common/message.rs#L13, which contains an encrypted payload - At night
@jaspervdm Why use PBKDF2 here? https://github.com/vault713/wallet713/blob/master/src/common/message.rs#L39
A PBKDF is only to help prevent brute forcing, but since there’s no user-entered inputs involved, it’s a waste of computing resources and unnecessarily slow
we're planning on implementing Grinbox, and a question came up.... Instead of using a federated server, why not use IPFS (or other pubsub service) for tx slates ?
Hi @keo glad to hear! Let me know if you need any help, here’s some integration instructions:
https://github.com/vault713/grinbox/blob/master/docs/integration.md
Quick answer to why not IPFS: To keep it performant, simple, and make messages transient. Over time, we’ve the ambition to make the entire system completely decentralized but opted to start with something really basic and straight forward that we knew we could make performant and re-evaluate later.
error[E0658]: imports can only refer to extern crate names passed with
--extern on stable channel (see issue #53130)
@jaspervdm @ravidio @lehnberg I'm releasing Grinbox support in Grin++ tomorrow, but I have a few more quick questions first.
1) Are you aware of any users generating non-standard addresses/versions? Is it better to require the version bytes to be correct, or would a warning be better?
2) Is anyone else hosting a grinbox server yet, or is it enough to only support grinbox.io addresses for now?
3) Any weird situations you can think of that I should be testing? It seems pretty straightforward - it either works or it doesn't. But I have a tendency to oversimplify things when I'm testing.
4) Does wallet713 only generate a single grinbox address per account? I couldn't figure out a way to generate a second, so that's all I was initially planning to support.
1) Are you aware of any users generating non-standard addresses/versions? Is it better to require the version bytes to be correct, or would a warning be better?
2) Is anyone else hosting a grinbox server yet, or is it enough to only support grinbox.io addresses for now?
3) Any weird situations you can think of that I should be testing? It seems pretty straightforward - it either works or it doesn't. But I have a tendency to oversimplify things when I'm testing.
4) Does wallet713 only generate a single grinbox address per account? I couldn't figure out a way to generate a second, so that's all I was initially planning to support.
awesome!
1) not as far as i know, currently wallet713 only supports the default version bytes for floonet and for mainnet. we are considering using specific bytes for other address types such as musig and swaps
2) so far only grinbox.io, but it wouldnt surprise me if more relays will pop up soon. at least i hope they will
3) not that i can think of otomh
4) users can switch to a different address: https://github.com/vault713/wallet713/blob/master/docs/usage.md#switching-address
1) not as far as i know, currently wallet713 only supports the default version bytes for floonet and for mainnet. we are considering using specific bytes for other address types such as musig and swaps
2) so far only grinbox.io, but it wouldnt surprise me if more relays will pop up soon. at least i hope they will
3) not that i can think of otomh
4) users can switch to a different address: https://github.com/vault713/wallet713/blob/master/docs/usage.md#switching-address
@DavidBurkett
Hi there, im trying to build grinbox on ubuntu 18.04 and im getting this error when running cargo build
error: no matching package named `grin_wallet` found
location searched: https://github.com/mimblewimble/grin
required by package `grinboxlib v1.0.1 (/home/daniel/grinbox/grinbox/grinboxlib)`
... which is depended on by `grinbox v0.1.0 (/home/daniel/grinbox/grinbox)`
Careful with deleting stuff if you have non-repository files there.