URI format for event ids

[LLFourn]

Here's an initial proposal for event ids that are URIs.
In many respects it can seen as a counter proposal to: #55 although I have moved closer to some of the ideas there is some respects (not adding price event types but just having more generic event types).

It doesn't include anything about HTTP APIs yet. It probably will eventually because it obviously lends itself to making easy HTTP APIs.

This is just for discussion of the idea and if this were to become a specification it would have to be re-structured and more consistently formatted. Hopefully it's readable!

[benthecarman]

Typo pass, found a bunch so I ran it through a word processor to find the rest

[LLFourn]

@benthecarman Ahh Thanks for that. Apparently I don’t have spellchecking on my fresh emacs setup (I am also bad at spelling).

[Tibo-lg]

I think at the end it's not really in opposition to #55 and seems more like a layer above to me. I think it will be nice to have common standard for event types, but I also feel like it is too restrictive to assume that for an oracle to publish an event it first has to make it standard. IIUC, it means clients need to be aware of all the event types out there, so if a new event type comes out, the client needs to be updated. I'm not sure I see why that would be better than having the client receive information on how to handle the event.

[Tibo-lg]

I'm not sure I understand this. How do you know they are attesting to the same event if you don't query them?

[LLFourn]

Err woops this is wrong. I wanted to say you don't have to inspect query response bodies to check this (rather just if it's 200 OK rather than 404).

[LLFourn]

I ended up removing this claim for now. I think portability is a concern but I wouldn't say the event id uri is the only way to achieve it.

[Tibo-lg]

@ is already a reserved character in URI syntax, it would probably be better not to reuse it otherwise it would make it difficult to use existing parsing libraries.

[LLFourn]

This is a good point. I think it's only reserved in the authority section strictly speaking? I'll have to experiment to see if it confuses parsers.

[Tibo-lg]

Yeah it might depend on implementations, but from my understanding of the rfc if you want to use "@" it needs to be percentage encoded.

[LLFourn]

It also might be annoying on twitter. Perhaps the url can just have a fragment and after the # we just serialize metadata like this that doesn't affect the outcomes in some way. So it doesn't appear in the URL but is signed in the announcement message.

[Tibo-lg]

I considered this as well, but I think the mantissa exponent as described in the original paper is actually better because you only need 2 R-values for any case and you don't have issues of going out of bounds.

[LLFourn]

I made an issue to discuss further: #65

[Tibo-lg]

How can a client make use of this?

[LLFourn]

Clients wanting to make a bet after digits(6) has been announced can use it. Clients who have already made bets on digits(5) have to just carry on with that and its possibly truncated outcome.

[LLFourn]

@Tibo-lg Thanks for your review

I think at the end it's not really in opposition to #55 and seems more like a layer above to me.

I think our ideas are less opposed than I originally thought.
This does specify a different way to serialize and combine events with other data when announcing and attesting. In your proposal it's a TBD TLV encoding where as here it's a single string for the event with things appended onto the end. This seems to be the important difference.

I think it will be nice to have common standard for event types, but I also feel like it is too restrictive to assume that for an oracle to publish an event it first has to make it standard

Note that this restriction isn't really to do with the event id URI idea per se. You could easily have an event type enum which works like Earth/Paris/2020-08-15/weather?enum(sunny,rainy,cloudy). The reason I don't like it is that it encourages the proliferation of bespoke events by oracles. There can now be another oracle that does Earth/Paris/2020-08-15/weather?enum(clear,rainy,cloudy) which just happened to choose a different identifier for the same thing. Is this not a concern for you? (would be interested to know other's opinions as well.

I tried to allow oracles to create their own even types without go through some public process. They just have to say in a (to be specified) machine readable way that "event types under this namespace may be from either the standard spec or my custom spec". Then they can define a new weather event type to mean ["sunny", "rainy", "cloudy"]. If we have a standard way to define enumerated event types then this could all be automatic. This is intentionally more involved than just returning an array in a HTTP response. On top of that it's more efficient.

[Tibo-lg]

There can now be another oracle that does Earth/Paris/2020-08-15/weather?enum(clear,rainy,cloudy) which just happened to choose a different identifier for the same thing. Is this not a concern for you? (would be interested to know other's opinions as well.

Personally I don't really see a big issue there. For me the purpose of the specification is to facilitate the development of client applications that can make use of the information provided by oracles to let users set up contracts. In that respect, there is not really any difference between both, and if the end user is not happy with the result values that they're proposed they can just chose a different oracle. I can also imagine that some oracles might want to sign even outcomes in different languages, in that case, does it mean we should standardize for every language?

I tried to allow oracles to create their own even types without go through some public process. They just have to say in a (to be specified) machine readable way that "event types under this namespace may be from either the standard spec or my custom spec". Then they can define a new weather event type to mean ["sunny", "rainy", "cloudy"]. If we have a standard way to define enumerated event types then this could all be automatic. This is intentionally more involved than just returning an array in a HTTP response. On top of that it's more efficient.

I'm not sure I understand what you mean here. I guess the user (or client app) would have to get hold of the event type definition somehow, so wouldn't that end up being the same at the end?

[nkohen]

I'm a little worried about capitalization

[LLFourn]

I think that proper nouns should be in capitals. So Binance and NBA. What do you think?

[nkohen]

I think it may be beneficial to add a version to the URI to make things more extensible

[LLFourn]

Sorry I missed this comment.
In my experience, versions in general make things less extensible because as soon as a client sees a version it does not understand it fails to parse whatever comes next. What kind of extensibility do you have in mind?

[Christewart]

Related to #88

[nkohen]

Any reason we shouldn't have the oracle specify its base (e.g. 10) to allow for binary or hex in the future should there be events where this makes sense to do?

[LLFourn]

No the digits event type could indeed take a base parameter.

[LLFourn]

I pushed some changes. The biggest one was that the event ids now start with / because I found it easier to get url parsers to work this way. I also removed the source identifier idea in favor of just signing metadata after a #.

@Tibo-lg

I can also imagine that some oracles might want to sign even outcomes in different languages, in that case, does it mean we should standardize for every language?

[edit] I read this wrong and responded to what I imagined I read. Sorry. I don't think that oracles will want to sign things in different languages for the same event. That would be redundant in a bad way.

Easy localization in general seems like an argument in favor of this proposal. If the oracle is allowed to specify an array of arbitrary strings with unspecified semantics then there's no easy way to create a localized client. If you have a weather event type now the client knows all the outcomes and their semantics can translate them for the user.

Although the event types are formally specified in English oracles are free to use paths how they like. For example a Nippon Professional Baseball game could have an event id /NPB/2020-09-01/東京ヤクルトスワローズ_阪神タイガース?vs and have an outcome 東京ヤクルトスワロ_win etc.

I don't think you have an English version of a NPB game or a Japanese versions of NBA events. Localization is the job of clients.

I'm not sure I understand what you mean here. I guess the user (or client app) would have to get hold of the event type definition somehow, so wouldn't that end up being the same at the end?

The difference is the clients can get the (immutable) event definition they which resolves the ambiguity of having [ "sunny", "rainy", "cloudy" ] in the event data (nonces) the client fetches each time.

[Tibo-lg]

This seems like an argument in favor of this proposal. If the oracle is allowed to specify an array of arbitrary strings with unspecified semantics then there's no easy way to create a localized client. If you have a weather event type now the client knows all the outcomes and their semantics can translate them for the user.

You've got a point, and my example was poorly chosen. But to summarize my opinion, I like (most of) your proposal, and I can definitely see standardization of events as useful and even necessary when it comes to using multiple oracles for a single event.

The point I disagree or maybe don't fully understand, is considering that all the information can be provided with just the URI.

The difference is the clients can get the (immutable) event definition they which resolves the ambiguity of having [ "sunny", "rainy", "cloudy" ] in the event data (nonces) the client fetches each time.

I don't really get what you are saying here. Where do they get the event definition from? How do they know it is the proper one?

[LLFourn]

The point I disagree or maybe don't fully understand, is considering that all the information can be provided with just the URI.

So far it seems like it will work since it is should not be that hard to describe a set of strings in a single human readable compact form.

To motivate this further I wanted to add "Trump vs Biden" event which is here: http://h00.ooo/Earth/USA/presidential-election/2020/Trump_Biden?vs
To add the event I just made a small cli and gave it: /Earth/USA/presidential-election/2020/Trump_Biden?vs
I can then complete it by giving it: /Earth/USA/presidential-election/2020/Trump_Biden?vs=Trump_win.
There is no annoying passing of lists of outcomes via the cli etc. There is also no need to access the database to check if Trump_win is a valid outcome for the event.

I don't really get what you are saying here.

Sorry! that should read.

The difference is the clients can get the (immutable) event type definition they which resolves the ambiguity of having [ "sunny", "rainy", "cloudy" ] in the event data (nonces) the client fetches each time.

"ambiguity" is not what I really wanted there. I think "brittleness" is more what I meant.

This is just an intuition and it may be wrong. My hope is that oracles will never need to do this and we can avoid even specifying anything like this. I have a feeling this is a bridge that can be crossed later. Perhaps allowing oracles to specify their own event types is the solution or maybe just an enumerate event type could be added so that an oracles can just list the outcomes in the event id.

[Tibo-lg]

There is no annoying passing of lists of outcomes via the cli etc. There is also no need to access the database to check if Trump_win is a valid outcome for the event.

Correct me if I'm wrong, but the reason you are able to do that is because you hard coded the event type and how to handle it right? If that's the case, I don't think it can scale to a large number of event types, and it means having to upgrade your code every type you want to add a new event, which is very inflexible IMHO.

[nkohen]

I think that there should be a built-in (so as to encourage use) versioning of event types in the URI.

[LLFourn]

I would hope explicit versions will not be necessary. If we screw up specifying weather, you can always make weather2 or perhaps weather.2 if we want to make visually clear it's a version.

(as side not weather is a bad example since I think it is not the type of thing people will actually use this for)

[nkohen]

It might be nice to have test vectors for parsing these examples, and in the future when encoding is specified it might also be nice to have serialization and de-serialization test vectors along with signature point computation ones.

[LLFourn]

Yes. I think there could be some basic ones in the URI format. Each document that specifies new event types should have have some more e.g. a vs parser should extract the team names.

I would like to do this soon but I want to avoid doing this inside this not very well focused document. I think each event type should be in its own document with test etc.

[nkohen]

So I think on a high-level I agree with Tibo that there is an issue of determining the outcomes should multiple oracles accidentally (or maliciously) decide to spec things slightly (or entirely) differently for the same event. As such, I think it should be important for the oracle to provide an endpoint where you can either query it directly for all possible outcomes (perhaps serialized in some descriptor fashion) or else at the very least you should be able to demand a signature of a hash of the specification they are following in some sense otherwise it may be very hard to generate a fraud proof for the oracle that is reliable.

[LLFourn]

@Tibo-lg made a point last meeting that you can have competitions with multiple entities. e.g. Top scorer in a competition. For this you could do /FIFA-world-cup/2021/top-scoring-player/Messi_Mbappe_Ronaldo?vs(3).

[LLFourn]

@nkohen

So I think on a high-level I agree with Tibo that there is an issue of determining the outcomes should multiple oracles accidentally (or maliciously) decide to spec things slightly (or entirely) differently for the same event. As such, I think it should be important for the oracle to provide an endpoint where you can either query it directly for all possible outcomes (perhaps serialized in some descriptor fashion)

I don't think making another descriptor is a solution to misalignment between the oracle and client. If the client is misaligned to the oracle then they can be misaligned in the implementation of this second descriptor as well.

or else at the very least you should be able to demand a signature of a hash of the specification they are following in some sense otherwise it may be very hard to generate a fraud proof for the oracle that is reliable.

Signing a digest of the specification they are following for the event type is a good idea. However, signing an entire spec is a bit much since if you change a typo then you're in trouble. Perhaps each event type can have a formal specification attached and that can be signed. I really like that idea and I think how sensitive the protocol is to correctness in this respect warrants it. It remains to choose a language.

[LLFourn]

I'll close this now.

The things that were concluded in the last meeting were:

1. Most people want the oracle to explicitly list all the outcomes when there are a relatively small number of them.
2. I can still follow this idea informally. All that I need to do is to transform the URI into the "full" descriptor in the announcement signature.