# I am the Watcher. I am your guide through this vast new twtiverse.
#
# Usage:
# https://watcher.sour.is/api/plain/users View list of users and latest twt date.
# https://watcher.sour.is/api/plain/twt View all twts.
# https://watcher.sour.is/api/plain/mentions?uri=:uri View all mentions for uri.
# https://watcher.sour.is/api/plain/conv/:hash View all twts for a conversation subject.
#
# Options:
# uri Filter to show a specific users twts.
# offset Start index for quey.
# limit Count of items to return (going back in time).
#
# twt range = 1 11
# self = https://watcher.sour.is/conv/p6pyuvq
Hey twtxt users I want to hear your opinions! Our Metadata Extension Specification does not explicitly state anything about empty values (empty keys, however, are explicitly forbidden). First I thought that empty values would be a good thing to have when implementing the fix today. Maybe useful for flags. But then, talking to @xuu on IRC arised two questions: 1.) What kind of flags even? 2.) Why would such a flag not have a value of "true", "on", "1", whatever? An empty value would probably be handled the same as an absent metadata field anyways. So why make it more relaxed than it needs to be? Thus I'm wondering, do you have any real use case where an empty value would be useful? Otherwise I'd say for simplicity we just require that both key and value must be non-empty. If a value is empty, the parser would treat it as a regular comment and not a metadata field. Since we add metadata to a list, we also can't reset a field using this technique either. Also, why would one want to reset a field? Glad to hear your thoughts.
@lyse \n> Otherwise Iβd say for simplicity we just require that both key and value must be non-empty. If a value is empty, the parser would treat it as a regular comment and not a metadata field.\n\nYes.
@lyse \n> Also, why would one want to reset a field?\n\nYou mean, change its value? How about nick, description, and/or URL change?
@fastidious Very good, ta! With resetting I meant "removing" the field, like undeclaring it. But that's way too enterprisey I guess and is completely opposite of what the code does at the moment. I think for nick and description specifically clients may just take the very last value and discard any previous ones. Other than bookkeeping a history of transitions, actually doing so would not add too much value, would it? As for the url field it might be beneficial to redefine the handling in the Twt Hash Extension Specification and state that the last (and not the very first) url must be used for hashing. Or introduce a new hashurl (or whatever it may be called) to be used for hashing. The parser could use the latest encountered hashurl from now on when generating the hashes. So when a feed moves to another URL it states the old and the new hashurl at the correct positions in the feed (haha, no ordering is mandatory) so hashes of older twts don't break. But that's a different story. Also much more thought needs to be put into that, too.
@lyse I believe my opinion is already known. A stricter spec is better IHMO and I see no added value (get it?!) for empty KV pairs in the metadata π
@lyse I believe my opinion is already known. A stricter spec is better IHMO and I see no added value (get it?!) for empty KV pairs in the metadata π
@prologic Absolutely. It appears there's not much interest in this topic, maybe wait a couple more days before finally settling on a decision.
@lyse Sure no worries. I think what little is left of the old Twtxt community probably donβt care or are unaware there is a new vibrant community growing. Will merge your PR on Sunday π
@lyse Sure no worries. I think what little is left of the old Twtxt community probably donβt care or are unaware there is a new vibrant community growing. Will merge your PR on Sunday π