On Aug 21, 2010, at 12:45 AM, sgoto wrote: > On Sat, Aug 21, 2010 at 12:43 AM, sgoto <[email protected]> wrote: > >> as far as i can understand, validation functions can't change either, >> unless all previous documents get reapplied the same validation function, or >> else replication will create a non-backward compatible merging conflict to >> be resolved.
yes, validation functions are not retroactive. furthermore, each user is in charge of her own validation functions, so some intermediate nodes may choose not to validate. >> >> the way i'm trying to solve this problem is having each database have one >> immutable validation rule: each document needs to be signed by a >> per-database-constant-public-key or by a PGP certificate signed by that >> public key (1 level of transitive trust, alla web of trust). why not just ensure that it is signed by any well-formed key? (in my model each user has a key, and you might input a message on your localhost, that replicates via N hops, to eventually reach my localhost, at which point I know the signature applies cleanly, so all I need to do is decide if I trust the key). >> >> does that make sense ? >> >> > > ah, one more question: does validation functions have access to the binary > data of attachments ? how can i make sure that the attachments are also > signed ? > no, attachments are not sent to the JS process. however, there is a ticket out, for including the md5 checksum of the attachment as part of the attachment stub. in that case, the md5 hash could be signed as well. Chris
