Can you point me to discussions had on this subject? I'm interested to know if any discussed ideas allow a snapshot to be referenced without developer involvement.
https://github.com/mastercoin-MSC/spec/issues/69This is from where I got the idea. You have a fair point. Snapshots should only be necessary for times of actual changes.
I was thinking about something similar as I was submitting my pull request. Maybe it's not necessary to revise the entire specification if only one or two small changes are made. If different sections are broken out one can submit pull requests for items that don't warrant an entire specification revision, and changes can be discussed in a context more relevant to the issue at hand.
If we consider the specification a dataset instead of a specific document, it may be reasonable to precisely define a type of transaction as a data point and discrete unit, and consequently revise that definition independently of any other definition. This also allows all changes to a specific definition to be queried, and a "timeline" built of changes relevant to a specific transaction type.
Good idea, this is what I have in mind, too. The current specification is more like a description than a short down-to-the-point set of formal definitions about the protocol.
Maybe a crazy idea, but why not use Master Protocol itself to store the specification? For the sake of opening up a discussion on the subject, consider if a transaction definition could be stored in the blockchain. Not only is it universally publicly accessible and immutable, but a standardized dictionary could theoretically allow a client to programatically and dynamically verify the validity of a transaction based on the relevant definition at the time. I have experience designing and implementing relational databases and would be thrilled to contribute if others think that this may be worth pursuing. I'm not under the impression that it's an easy task, but then again, neither was a distributed exchange.
Hahaha. I like the way you think. This is nothing that can be done in a short timeframe though. You'd need a) a agreed upon format to publish the data, b) define who is allowed to push changes, c) a way to fetch the data and d) an interpreter.
IMO, this is unnecessary. I don't see any reason why a properly formed transaction definition shouldn't be able to determine validity of all applicable transactions. Archival could imply more limitations than the benefit gained by ease of gathering examples. Maybe your concern here could be appeased with the ability to prove a transaction types definition at block x?
What I was thinking about was something to reduce the need of multiple parsing engines or the need of processing all MSC transactions. Say there are three specification revisions. Newer clients don't necessarily need to implement the older ones, if they could simply import all historical data up until point X.
You may join the
developer group/mailing list. I can't really comment on the rest, because I neither have an insight about what happens behind the curtain nor do I have the authority and general knowledge about how "things are done here". Rephrased: I think you have great ideas, but I don't know how you should and could convert them.
