Earlier quoted context omitted.
When I was faced with this (signing a structure), I serialized the json into base64, then put that base64 string as a value (along with the MAC) into a new json document. It of course increases deserialization overhead (json, verify, unbase64, inner json) but sidesteps this issue. I thought about sorting keys and other things like that, and the dozen edge cases and potential malleability issues dissuaded me for the c…
Use Bencoding, like bittorrent does: https://en.wikipedia.org/wiki/Bencode As I put in another comment, a torrent id is a hash of a map, where one of the keys contains binary data. bencoding solved that decades ago already.
Scuttlebot: Peer-to-peer database, identity provider, and messaging system
111–120 of 123 posts
Re: Scuttlebot: Peer-to-peer database, identity provider, and messaging system
#112Earlier quoted context omitted.
it is, I tried with haskell and gave up when I noticed I couldn't easily get json serialization to be in the same order as the javascript implementation and therefor couldn't verify nor sign messages with interoperability with the current clients.
> I tried with haskell and gave up when I noticed I couldn't easily get json serialization to be in the same order as the javascript implementation and therefor couldn't verify nor sign messages with interoperability with the current clients. This gets you most of the way there: > With the Aeson library, the order of keys in objects is undefined due to objects being implemented as HashMaps. To allow user-specified ke…
Re: Scuttlebot: Peer-to-peer database, identity provider, and messaging system
#113Earlier quoted context omitted.
Basically Scuttlebot is a collection of linked lists (or blockchains if you will) because you only have to discover one message to be able to fetch the rest of the related content, since it's all linked as a DAG.
Yeah, so this is the design decision that I don't really understand. Each message on the blockchain contains the author's public key representing his identity. If I already know the identity of the author, I could just go ahead and befriend him and later ask him or other peers who are his friends to share his "feed" with me. If the feed lives in a relational DB, I could then use SQL to ask for particular messages lik…
It's probably a result of going with pull-streams and basically architecture all scuttlebot tools/libs around pull-streams, so you want something that works over streams.
And yeah, Scuttlebot is not built with SQL as it's query language, but you could probably easily write something that understands both SQL queries and the file format scuttlebot stores the messages in. Thing is, you don't want to send these queries to other peers (they are all local), because the system is setup to be offline-first and only reach out to the network when it has to, not just for listing latest messages.
In general, you want all the action of fetching/syncing of data to happen exactly when you want it to happen, and then when you're done it doesn't continue until next "sync". So everything you do is local.
But then, if "query the feeds the way I want to" is the reason you don't like it, then so be it. But if it's just that you don't understand it, then reading through and digging into the different repositories will give you a better viewpoint. Start at the ssb-query and look what's using it and what it's using.
Re: Scuttlebot: Peer-to-peer database, identity provider, and messaging system
#114Earlier quoted context omitted.
I think npm is barely a package manager. Yarn is a bit better, but it’s also my experience with most of the stuff in the JS ecosystem.
I think the quality of X doesn't determine what X is. npm is a package manager, it manages packages for you. Hard to escape that fact. It's a bit rubbish, but it doesn't make it _not_ a package manager. Same with the USA, might be a shitty country, doesn't mean it's barely a country
If you get too far from what people aim to use your tool for, are you still a tool for x?
Re: Scuttlebot: Peer-to-peer database, identity provider, and messaging system
#115Earlier quoted context omitted.
> I tried with haskell and gave up when I noticed I couldn't easily get json serialization to be in the same order as the javascript implementation and therefor couldn't verify nor sign messages with interoperability with the current clients. This gets you most of the way there: > With the Aeson library, the order of keys in objects is undefined due to objects being implemented as HashMaps. To allow user-specified ke…
Well, the problem is replicating the javascript order which isn't lexicographical. :/
Given the example:
{
"baz": ...,
"bar": ...,
"foo": ...,
"quux": ...,
}
Then listing all of the keys in your desired order: comp :: Text -> Text -> Ordering
comp = keyOrder ["foo","bar","baz","qux"] `mappend` comparing length
Note if you list all keys in the first argument of keyOrder it never goes to comparing length. There is probably a cleaner way to denote that this is the case but I can't be bothered to figure it out atm.You can use this function:
encodePretty' defConfig { confCompare = comp } YourType
And it will produce: {
"foo": ...,
"bar": ...,
"baz": ...,
"quux": ...,
}
Can you give a sample of the javascript in the order necessary? This is from NPM? They have to use some comparison function to figure out how to sort their keys I'd imagine, so you could just copy that with Haskell.Re: Scuttlebot: Peer-to-peer database, identity provider, and messaging system
#116Scuttlebutt is a neat concept, burdened by a bad protocol. Signing a message involves serializing a json object, signing it, adding the signature as a field on that json object, and then serializing it again. To verify, you deserialize the message into an object, remove the signature field, and then reserialize it, and verify the signature against that new serialization. This means that all the clients have to have a…
Re: Scuttlebot: Peer-to-peer database, identity provider, and messaging system
#117Scuttlebutt is a neat concept, burdened by a bad protocol. Signing a message involves serializing a json object, signing it, adding the signature as a field on that json object, and then serializing it again. To verify, you deserialize the message into an object, remove the signature field, and then reserialize it, and verify the signature against that new serialization. This means that all the clients have to have a…
When I was faced with this (signing a structure), I serialized the json into base64, then put that base64 string as a value (along with the MAC) into a new json document. It of course increases deserialization overhead (json, verify, unbase64, inner json) but sidesteps this issue. I thought about sorting keys and other things like that, and the dozen edge cases and potential malleability issues dissuaded me for the c…
Personally I'll just concatenate the values in a defined order and sign/hash that.
Re: Scuttlebot: Peer-to-peer database, identity provider, and messaging system
#118Earlier quoted context omitted.
Basically Scuttlebot is a collection of linked lists (or blockchains if you will) because you only have to discover one message to be able to fetch the rest of the related content, since it's all linked as a DAG.
Yeah, so this is the design decision that I don't really understand. Each message on the blockchain contains the author's public key representing his identity. If I already know the identity of the author, I could just go ahead and befriend him and later ask him or other peers who are his friends to share his "feed" with me. If the feed lives in a relational DB, I could then use SQL to ask for particular messages lik…
Re: Scuttlebot: Peer-to-peer database, identity provider, and messaging system
#119Earlier quoted context omitted.
I think the quality of X doesn't determine what X is. npm is a package manager, it manages packages for you. Hard to escape that fact. It's a bit rubbish, but it doesn't make it _not_ a package manager. Same with the USA, might be a shitty country, doesn't mean it's barely a country
Depends I think. If you make a package manager, but the only function it has is text editing, is it a package manager? If you get too far from what people aim to use your tool for, are you still a tool for x?
If it quacks like a duck, looks like a duck, it's a duck. If it doesn't quack and doesn't look like a duck, it's not a duck. So in your example, if npm just provides text editing, I'd call it a text editor, not package manager. If it manages packages, I'd call it a package manager. So this is judging things based on their functionality, rather than what they want to use it for.
Don't think the intended purpose matters too much in what something is. It is what it is, it is not what it was aimed to be but what the current state of it is.
And AFAIK, people _mostly_ use npm for managing packages, other use cases are not nearly as popular (like distributing assets).
Re: Scuttlebot: Peer-to-peer database, identity provider, and messaging system
#120Earlier quoted context omitted.
Yeah, so this is the design decision that I don't really understand. Each message on the blockchain contains the author's public key representing his identity. If I already know the identity of the author, I could just go ahead and befriend him and later ask him or other peers who are his friends to share his "feed" with me. If the feed lives in a relational DB, I could then use SQL to ask for particular messages lik…
The idea behind this is that it's streams all the way through, so there could be something more efficient to use for these "rolling" database that basically are streams of data. So instead of SQL, it's map-filter-reduce, a query engine that works over streams. https://github.com/ssbc/ssb-query/blob/master/README.md - https://github.com/dominictarr/map-filter-reduce It's probably a result of going with pull-streams an…
Is there any dev forum on ssb or other place I could catch you guys at if I want to learn more or contribute?