Abuse j.fact - The distributor should be able to issue 403 forbidden, 400 bad request

[leblancmeneses]

Since j.fact can be issued easily how do you monitor and prevent gigs of data being created by a malicious user/script?

Can you also address data validation? I'm guessing it would begin to mirror firebase's https://www.firebase.com/docs/security/api/

[michaellperry]

Facts will be authorized according to the security predecessors. I foresee locking the distributor down in a couple of ways:

1. Every fact needs to be signed
2. Only facts matching a given set of "shapes" will be accepted

By "shape", I mean the analog of type and version from Correspondence. I'm not yet sure how to express that in Jinaga without rubbing up against the dynamic nature of JavaScript.

These lock downs need to be opt-in so that you begin development with a wide-open distributor. You only lock it down once you have a pretty good idea of your model.

[leblancmeneses]

This is the direction firebase is going with their data validation and security.

https://github.com/firebase/bolt/blob/master/docs/guide.md

IMHO metadata should be separated from the facts. This way it can be exposed as an endpoint and rendered on the UI (validation, form fields, ect) and the distributor can consume the metadata to validate and apply security rules. I do not fully grasp how you can accomplish this with your message properties.

[michaellperry]

With the authorize function, you can shut down unauthorized facts. This also separates authorization rules from the facts themselves, and does not rely upon pre-determined conventions. This should address the concern.