> 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. 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. > 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. I’m enough of a lisp weenie that I don’t think of the two as distinct models. Code and data are, in important ways, the same thing - what’s important is the interpretation of that data. The JSON-Patch approach I’m using is, arguably, a programming language - albeit a very inexpressive one which can only write programs that terminate in constant time and which use constant space. I think you’re right that the annotations need to be more powerful than that - I’m not convinced they need to be turing-complete, but I think there’s a strong case that linear programs aren’t sufficient. There are complicated constraints, though. One - I’m not up to allowing arbitrary internet persons to upload code if that code could even potentially escape from the service or access code or data held by the service other than the state currently being evaluated. Sandboxing support is weak in a lot of languages - even Lua has primitives for basic IO, and they’re surprisingly hard to disable completely. Blizzard has spent years chasing sandboxing bugs in their own Lua implementation. This complaint extends to V8, embedded Python, “just use execfile”, Ruby, shell scripts, and most embedded languages. Two - I would dearly like to be able to query the service for things like “show me all the emails in this date range that affected my Shiny balance.” In a fully turing-complete language, that property is not necessarily computable, and it’s certainly not computable in any widespread language. The python-ish program if balances.o >= 5: balances.o -= 5 balances.Aris += 5 else: warn(‘transfer failed: o had ‘, balances.o, ‘ Shinies, not 5’) might safely record the transfer of 5 Shinies from me to you, but good luck interrogating the program to determine, statelessly, which properties it might touch. Even static analysis can be defeated, in many languages: simple reflective programming tools, like python’s getattr(), throw that out the window entirely. Three - most languages have heinously poor human factors and approachability. If there’s to be any hope for random Agorans annotating messages, it has to be more usable. That - sorry - rules out Python, Ruby, pretty much any Lisp, ML, Rust, Golang, PHP, C, C++, and probably even BASIC. I’m actually a bit tempted to look at tools like Excel, where “non-programmers” regularly pick up enough programming skill to get by with by simple act of using the tool. Are there other such tools? I mean to look outside of what most people think of as “code.” Four - it is an article of faith for me that it is impractical and unwise to encode the rules of Agora into the language. The rules change over time; this should not change the interpretation of annotations on historical messages when it happens. The rules change frequently; that should not impose much, if any, maintenance burden on the tool or on its users. And so on. Instead, I think the way to make this work is to provide semantics that are clear and comprehensible, and composable tools that build on that. There are a number of themes that crop up in Agora’s rules that are not, themselves, rules. The example above, of transferring a value by arithmetic, is a common one, but there are numerous others. I suspect that being able to represent those common themes, and being able to compose them, is far more important than complete rules coverage. 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. > o, honestly, this is an amazing idea. This is such a brilliant > solution to the entire problem that I'm kind of kicking myself for not > coming up with it (not that I would have been able to implement it if > I had). Thank you! I was concerned I was crazy - not concerned enough not to try it anyways, but concerned enough that I’m surprised and relieved by this reaction. -o
signature.asc
Description: Message signed with OpenPGP
