is-my-ssb-valid

Build message validators for scuttlebutt using JSON schema.
Uses is-my-json-valid under the hood

Example usage

const Validator = require('is-my-ssb-valid')
const profileSchema = require('ssb-profile/spec/profile/schema')

const isProfile = Validator(profileSchema)

const A = {
  //....
}

isProfile(A)
// => true | false

console.log(isProfile.errors)
// => null | [Error]

const pull = require('pull-stream')

pull(
  sbot.messagesByType({ type: 'profile/person', reverse: true }),
  pull.filter(isProfile),
  pull.take(50),
  pull.collect((err, profileUpdates) => {
    // ...
  })
)

API

Validator(schema) => isValid

expect a JSON schema

isValid(msg) => Boolean

where msg can be any of

• a full message a "full message" of form { key, value, timestamp }
• just the value of a message (msg.value)
• just the content field of a message (msg.value.content)

If the last message tested came back invalid ("false"), then you can also check out the specific errors:

• isValid.errors will be populated with those errors
• isValid.errorsString will be populated with a (crudely) flattened version in case you need a String

just a code snippet I've got sick of copying and pasting and use (some variation of) is so many repos.

Other client devs who might use this : @soapy 🐶 @christianbundy @Hendrik Peter

hey thanks @mixmix!

@mixmix Thanks for the work on this <3. I've started adding support for this in the new patchfox. Is there a repo or module of JSON schemas?

I'm asking because in using this search, I've found a bunch of them and don't know which one to use and if they are up to date. I've used deprecated modules in the past without knowledge...

@SoapDog definitely ask. I think most all of them are up to date.

Note with #ahau work I've started putting them directly in the project using them in folders like spec/profile/schema.js (for ssb-profile)

@mixmix I had problems using them from the client-side. I have a fork of ssb-ref here that doesn't use the ip module, but there were other problems which I don't remember out of the blue but they usually boiled down to modules or dependencies trying to us fs.* to read stuff at runtime such as grammar files. All these fail to browserify properly.

Many of these schema draw from a shared ssb-schema-definitions, and this in turn draw some regex from ssb-ref. I was surprised to see that ip module in there too recently. Could be something we could / should squash, or perhaps we can side-step this by extracting ssb-id-regex which can then be consumed whatever without pulling in the ip...

@SoapDog

@mixmix,

I have a fork without ip in it. The problem is that there are other moments where it access files on disk which the path is not known at build time so it can't be snowpacked. Or at least it didn't work some months ago. I just went to check the dependencies again because I don't remember which one was giving me trouble. I thought that multiaddress had raw access to a grammar file but checking right now I can see it is accessing the compiled version so it is not it. I don't recall which one was the problem, just that I was forced into browserifying things because somewhere down in the dependencies chain for ssb-schema-definitions there were requirements for os and fs, both of which can't be handled by snowpack but can be handled by browserify.

ok, well this doesn't effect me (yet) @SoapDog but am happy to support a good fix being merged. Let me know