4 ms·
Correct. This is yet another "hosted platform for revenue" open source project; if you deploy on your own servers, you don't pay us. Servers have no access to
by nbadg 10y ago
Correct. This is yet another "hosted platform for revenue" open source project; if you deploy on your own servers, you don't pay us.
Servers have no access to plaintext. They also have extremely limited metadata: only the "author" [1] of the data and its ciphertext length is known.
[1] Technically not the author but the "binder", which is a specific term used in the protocol, but we're getting a little deep into the weeds. See here for more info about binders: https://github.com/Muterra/doc-golix/blob/master/whitepaper.md#data-retention-and-removal https://github.com/Muterra/doc-golix/blob/master/whitepaper....
- StavrosK 10y agoThat's pretty cool, thanks. So I don't need to worry about deploying MQTT servers and authenticating between them, I can just use this. Can I suggest this alternative API: obj = hgxlink.new_threadsafe(cls=hgx.JsonProxy, state='Hello world!') obj.share_threadsafe(bob) becomes: bob.send({"some": "serializable object"})
- nbadg 10y agoThe API is definitely more cumbersome than I would prefer. I really like this idea: > bob.send(obj) However, I don't think object creation and sending will ever be combined into the same operation, because: + objects don't need to be shared (imagine using an object to track application settings; you don't want to send that to Bob but you want it to persist across sessions) + objects can be shared with more than just Bob (and we'd like it to be the same object!) So hopefully, in the future the API will look more like: > obj = hgx.JsonProxy('hello world') > bob.share(obj) Unfortunately because of the async/await syntax, this gets a little complicated to implement. But it's definitely on the horizon.
- StavrosK 10y agoOh, I see, so not everything is 1:1. That makes sense then, thanks.