> On Oct 5, 2017, at 11:32 PM, Owen Jacobson <o...@grimoire.ca> wrote: > > >> On Sep 29, 2017, at 4:00 AM, Aris Merchant >> <thoughtsoflifeandligh...@gmail.com> wrote: >> >> I love this idea. It seems very practical without sacrificing >> usability for the end users (i.e. the players). I have a few >> suggestions: >> >> 1. Who annotates. I think giving everyone access to the annotation >> interface would probably make sense. You can't personally annotate >> every message affecting the entire gamestate, and I'd love to help set >> the formats I'm consuming for Promotor. nichdel came up with a >> proposal format suggestion, and now that this has come along I'm >> modifying it to have more information for the Promotor side of the >> Promotor-Assessor pipeline. I'm sure other officers have input on how >> formalization for their parts of the gamestate should take place, and >> they have a unique understanding of what information is needed to do >> their jobs. > > This is, I strongly believe, the correct answer. We’re none of us as creative > or as thorough as all of us, just as a starting point, but I do genuinely > believe this could be useful for other officers, and even random Agorans. It > might also help provide some continuity between officers if it works out. > > Right now, the API for this thing is totally unsecured - no authn or authz, > no abuse detection, no rate limits, nothing. I trust Agorans fairly far, and > I don’t think anyone here would make a problem out of this - other than maybe > by putting in intentionally-bogus annotations to try to cause self-ratifying > reports to be wrong in useful ways, anyways - but that trust does not extend > to the internet at large. I’d like to address that, or at least to add some > username/password/API token authentication even without any authorization > layer, before I open it up further.
I’ve implemented this (https://github.com/ojacobson/cadastre/commit/270f506ca8f8a920748eee42473cf220ed165d19 <https://github.com/ojacobson/cadastre/commit/270f506ca8f8a920748eee42473cf220ed165d19>), which means I feel comfortable publishing the URL now. Cadastre is available at https://cadastre.herokuapp.com/ <https://cadastre.herokuapp.com/> with an API documentation endpoint at https://cadastre.herokuapp.com/docs/ <https://cadastre.herokuapp.com/docs/>. This is NOT A LAUNCH ANNOUNCEMENT, since the docs are woefully incomplete - a bare list of endpoints doesn’t really qualify - but you can see the data I’m using to generate the Surveyor’s report by poking the compute_state endpoint: https://cadastre.herokuapp.com/docs/#compute_state <https://cadastre.herokuapp.com/docs/#compute_state> > The other blocker for general adoption is a user interface. Right now I have > a CLI tool (https://github.com/ojacobson/cadastre-cli/), and I plan on > publishing docs for the HTTP API to hopefully make it possible to do other > things with this, but there’s no HTML UI. I don’t think that’s viable if > anyone other than the most hard-core software heads are going to touch it. I’ve still been focussing on the CLI I use to work with this document store, but I still think an HTML UI is essential. I put it off because… >> 2. Annotation style. As you've mentioned, your format is a bit forced. >> You're doing a great job with what you have to work with, but I think >> the basic problem may be that you're trying to use markup to represent >> transactions. It works wonderfully for representing the data (and >> should probably be a base format for that), but poorly for >> representing things like conditional actions. You can add and add to >> the format, but you'll just be making it more complicated to use. I >> suggest you consider using programs (possibly with methods you >> provide) as annotations. It feels kind of intuitively weird to >> represent an annotation as a program, and they don't have the nice >> formal properties the data itself does (except maybe if you used >> Haskell or something), but I think it might be a lot more practical >> for actual use. Programs allow for loops, unrestricted conditionals, >> and the like, meaning that you don't have to work something out by >> hand or create a new transaction type just for one complicated >> transaction. They would work well for this because they take data and >> compute changes, which is exactly what our action system does. There >> is thus a neat one-to-one correspondence between an action and a >> program. …Aris was right. Patch-style annotations are impractical at any kind of scale, because they’re not flexible enough, and fixing that issue requires coding a surprising amount of Agora’s rules into the system. I’m not up for that; I’d prefer to keep the rules on the outside. > All of which is a long-winded way of saying that if the annotations are code, > then I suspect we’ll have to design a programming language. That’s not > terribly daunting to me - I’ve done language work before - but I might put > that off and use json-patch for now to demonstrate the basic concept, then > write a tool for converting json-patch annotations to code annotations once > it’s clearer what that code should look like and how it should be evaluated. So I did this. Over the last week, I wrote a lisp implementation in Python (https://github.com/ojacobson/actinide <https://github.com/ojacobson/actinide>), since I couldn’t find an embeddable language that was both usable (sorry, V8) and reliably unwilling to give its users filesystem access (sorry, Lua). It’s still a work in progress, but it’s runnable, and I’m going to take a shot at replacing the Cadastre annotations system with tiny lisp programs “soon.” I hope these updates are interesting. Cadastre is an ambitious project, but I think its goals are within reach. Writing up these reports gives me a chance to reflect on progress, and a chance to seek further input. -o
signature.asc
Description: Message signed with OpenPGP
