This is a set of prototype examples for lovescript.
Lovescript is an experiment to distill the essential protocol.love information interface of a real-world agreement/contract.
To explore the interfaces to protocol.love using techniques such as Domain Specific Language, semi-structured data, paper prototyping, diagrams, etc.
A purpose of automated tooling is to facilitate existing manual processes by reducing repetitive work, tracking information in real-time, & providing logical feedback on the design of a system.
To work with automated tools, one must interact with a set of interfaces. There are various interfaces in a process & software stack.
This repo is an exercise to understand how the protocol.love api is used in service of real-world agreements & contracts. Examples of the protocol.love api being used in a stepwise & semi-formal fashion will demonstrate the veracity of the protocol.love api concept and to root out architectural misunderstandings & bugs in the api & process itself.
The profession of Software Engineering has discovered patterns to reduce risk, increase applicability of software, increase productivity (short, medium, & long term), & increase the ability to manage complexity. Separation of concerns is a pattern/strategy to manage complexity, reduce risk, increase applicability of software, & increase productivity in certain cases.
In the context of protocol.love, separating the concerns of agreement design & tracking from "currentsee" exchange, we will be able to contribute more value to the public ecosystem & further enhance our goals of "vulnerable transparency" by increasing the applicability & de-risking certain aspects of participating individuals & collectives (entities).
See https://docs.google.com/spreadsheets/d/13gwZp_jv9m76Ga3-4j68P-evyVByZjawVAyH3TU4kyw for using Google Docs to track the design of an agreement.
The syntax is experimental & example driven to explore the syntax.
A simple work for hire example