On 11/7/19 11:20 PM, Aris Merchant wrote:
1. Contract patency. A pact is made the same way a contract is made now, but has only the powers suggested by G. To become a contract, a pact is made patent. This can by done with the consent of the parties by publishing the full list of parties and the text. If the pact is made in public, the intent of the parties to make it patent is presumed. A contract (that is, a patent pact) CANNOT have a change to its party list or text that isn't made in public.
Implementation question: when a contract changes its text, does that mean the change simply doesn't take effect until someone bothers to publish the updated full text?
2. Covenant introduction. Covenants are a class of entity that have a set of persons who are privy to the covenant and a subset of that set who the covenant is binding upon. A covenant cannot become binding upon a person without their consent. A covenant's properties can generally be changed either i) with the consent of everyone who is privy to that covenant; or ii) without objection.
If I'm understanding what you mean by people being "privy" to the covenant, then how is consent determined? It seems meaningless (or at least weird) to have to publicly consent to changes to a private document.
This could be done by moving the special case text for pledges to apply to all covenants, in an excellent example of the DRY benefits of a consolidated architecture.
I'm thinking back to my attempt at "binding" entities, and I didn't make pledges binding because they aren't phrased in the same way that contracts/rules generally are. "I will foo if bar" vs "Jason Cobb SHALL foo if bar." I don't think it's unimplementable, I just think this would require some careful wording or changes to the way that people would make pledges.
3. Promise introduction. A promise behaves roughly as it did in 2013. A promise is a covenant which is privy to its creator and its owner and becomes binding upon its creator at the time it is cashed.
Oooh, this sounds interesting. I'd been doing some archives diving and seen promises, but I hadn't quite gotten/bothered to look up how they worked. Thanks for the link!
Potential objections: A) Covenants are too complicated. Answer: This is... actually a very fair objection. Generality always means a more complex system. On the other hand, this unifies a bunch of existing systems that have many things in common. Nothing else actually depends on introducing covenants. I like the idea of getting rid of redundancies, and I think it could be done in a way that isn't too complicated. However, it's possible others will disagree.
I don't think they're too complicated in principle, but I think it would come down to how the wording is written.
Thoughts? -Aris
Seems like a good idea to me. -- Jason Cobb
