#82
Issues/mitchellh/vouch/#82

Proposal: API Change

OpenDitherDudeopened 7mo ago

PreScript: writing this at the end, syntax will look like [action][(provider|FQDN)](@userID[:username]|:username)[REASON] square brackets are optional, round brackets for the EITHER/OR syntax split by the pipe.

  1. Optional + when vouching; i.e. it should be supported by the parser, so 
    +ditherdude
# is the same as
ditherdude

    Whilst this looks prettier when viewing as a diff file, it also allows for in the future to be able to vouch/denounce someone ip the provider starts with a "-" (def. not talking from exp of owning a domain that starts wyth a hyphen and every service breaking)

  2. If a provider contains a dot (.), treat as url. (so github.com is the same as github, following the vouch example md)
  3. optional userid. I havent checked the code, but acc to the issues this isnt in yet? mark with @ symbol, reads until ':'.
  4. @include https://.../vouched.td to include other vouch files; latest change is the one that persists (so put includes above repo-defined vouches). I kn;w this is a topic of much debate, im just asking that the parser /lexer support this syntax so it can be implemented later on.
  5. extending on (4), ! action to reset vouch status to nothing (useful if an included vouchlist donounces someone but yiu dont want to vouch them)

    6. ive tried to implement the above in a way thrt doesnt break any current conf (backward-compatible), rhilst also being future proof (as importing vouched files is not planned at this point AFAIK) or at least a common standard if ppl will eg fork to add importable include files.
    EDIT: changed to HTML cuz MD made this whole issue a header???

Activity

5
RowanDavitt7mo ago
  1. optional userid. I havent checked the code, but acc to the issues this isnt in yet? mark with @ symbol, reads until ':'.

There should be something that is unique and persistent for each user. on github each user has a unique number id (for example mine is 116852751), I'm not sure if this what you mean by userid but they probably shouldn't be optional. This is related to https://github.com/mitchellh/vouch/issues/20.

ive tried to implement the above in a way thrt doesnt break any current conf (backward-compatible), rhilst also being future proof (as importing vouched files is not planned at this point AFAIK) or at least a common standard if ppl will eg fork to add importable include files.

For backwards compatibility, at least while the syntax is still being developed, it might be good to start including a line that indicates how the file is formatted, so that the lexer/parser can tell what information is included and where to find it. It might be possible to do this as a regular expression, if the syntax is regular (I haven't really checked if it is), that the parser/lexer can just pick up use, then there would also need a list a headers to tell what each group maps to. though now that I think about it, this might be more difficult when there are multiple files with different formats.

alternatively we could add version numbers for big changes and then ideally the lexer/parser would change would know to parse that specific version of syntax. though this could make the parser considerably more complicated.

I guess it could maybe be possible to just have the bot update existing files whenever the syntax changes.

PreScript: writing this at the end, syntax will look like [action][(provider|FQDN)](@userID[:username]|:username)[REASON] square brackets are optional, round brackets for the EITHER/OR syntax split by the pipe.

This is a really small and pedantic thing, but the syntax should be [action][(provider|FQDN):](@userID[:username]|username)[ REASON]. The colon should be after the provider/FQDN instead of before the username and there should be some white space separating the username from the REASON

RowanDavitt7mo ago
  1. optional userid. I havent checked the code, but acc to the issues this isnt in yet? mark with @ symbol, reads until ':'.

There should be something that is unique and persistent for each user. on github each user has a unique number id (for example mine is 116852751), I'm not sure if this what you mean by userid but they probably shouldn't be optional. This is related to https://github.com/mitchellh/vouch/issues/20.

ive tried to implement the above in a way thrt doesnt break any current conf (backward-compatible), rhilst also being future proof (as importing vouched files is not planned at this point AFAIK) or at least a common standard if ppl will eg fork to add importable include files.

For backwards compatibility, at least while the syntax is still being developed, it might be good to start including a line that indicates how the file is formatted, so that the lexer/parser can tell what information is included and where to find it. It might be possible to do this as a regular expression, if the syntax is regular (I haven't really checked if it is), that the parser/lexer can just pick up use, then there would also need a list a headers to tell what each group maps to. though now that I think about it, this might be more difficult when there are multiple files with different formats.

alternatively we could add version numbers for big changes and then ideally the lexer/parser would change would know to parse that specific version of syntax. though this could make the parser considerably more complicated.

I guess it could maybe be possible to just have the bot update existing files whenever the syntax changes.

PreScript: writing this at the end, syntax will look like [action][(provider|FQDN)](@userID[:username]|:username)[REASON] square brackets are optional, round brackets for the EITHER/OR syntax split by the pipe.

This is a really small and pedantic thing, but the syntax should be [action][(provider|FQDN):](@userID[:username]|username)[ REASON]. The colon should be after the provider/FQDN instead of before the username and there should be some white space separating the username from the REASON

DitherDude7mo ago
  1. Yep thats what I meant
  2. could even be a bash-like shebang #!/bin/vouch 3 lol
  3. oops my bad.
DitherDude7mo ago
  1. Yep thats what I meant
  2. could even be a bash-like shebang #!/bin/vouch 3 lol
  3. oops my bad.
RowanDavitt6mo ago

With including other files, using the full URL every time could get pretty messy. URLs can get pretty long and include information that isn't very important. For example, the URL for the VOUCHED.example.td file in this repo the url would be: @include: https://raw.githubusercontent.com/mitchellh/vouch/refs/heads/main/VOUCHED.example.td

it might be good to have a more complex syntax like @include: ([platform:|FQDN:] (repo_name|repo_ID)[ [branch:[commit:]]path]*|URL)

Where if no platform is given, its assumed to be the same as the repo the file is in. If no branch is given its assumed to be repo's default branch (or main). if no path is given its assumed to be in some default place (like a file called VOUCH.td in the base directory).

This would make it more intuitive and easier to read, especially if someone wants to include multiple files from the same repo. this might also make it easier if we want to use a platform's API for fetching files from it.

So like the VOUCHED.example.td url could become: @include: github: mitchellh/vouch main:VOUCHED.example.td or could be simplified to: @include: mitchellh/vouch VOUCHED.example.td and then if we want to include another file from the repo, .github/VOUCHED.td, we can write: @include: mitchellh/vouch VOUCHED.example.td .github/VOUCHED.td