Open hboon opened 4 years ago
I must have forgotten to mention that the expression is taken from RFC 2254 which is often used to filter attestable data objects. It is part of a serial of RFCs which also defines stuff like RDN and incorporates older ANS.1 stuff like objectClass for use on the Internet (i.e. web1)
* There seems to be special/reserved attributes like `balance` (or not).
Yes, but not 'balance'.
Currently, balance is hard-coded but that's not the intention of TS design, but an expedience 'cos we missed the target of "default ERC20 tokenscript" back in May and never got that back until now.
There are needs for reserved attributes like "owner_address", "today".
Reserved words like TRUE and FALSE are defined in RFC2254.
AND/OR
Polish notion per same RFC. Examples:
' gives all attestations that can be used to prove age
(&(birthDate=*)(expiry<=20200421000000))
† Where 2020-04-21 is Generalised Time
(&(birthDate=*)(expiry<=${today}))
We only support <=
and >=
'cos there is no <
and >
. Also not is !
We have
(|(from=${ownerAddress})(to=${ownerAddress}))
Regex?
Any directory service has ruled out Regex as it's impossible to project cpu cost. It's more useful where you own the host. I think the same consideration applies here, e.g. if you aply a filter for a token, or an offer, in a market place, you can bring it down with DDOS fairly quick if it allowed regex.
cc @JamesSmartCell
Useful for implementing the parser as well as for TokenScript authors.
i.e. for example:
expired=TRUE
in:Particular areas of interest:
balance
(or not).