# 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 8
# self = https://watcher.sour.is/conv/6ishh6q
ok so i have found a genuine twt hash collision. what do i do.
internally, bbycll relies on a post lookup table with post hashes as keys, this is really fast but i knew i'd inevitably run into this issue (just not so soon) so now i have to either:
1) pick the newer post over the other
2) break from specification and not lowercase hashes
3) secretly associate canonical urls or additional entropy with post hashes in the backend without a sizeable performance impact somehow
@zvava we have to amend the spec and increase the hash length. We just haven't done so yet 😆
PR is up for review though 🤞
@prologic i just added timeline refresh to bbycll and it is so convincing i almost replied to you from there hehe, can i get a link pretty please :o
@zvava For the time being, just show both.
@prologic I completely forgot about that topic … 😂🥴
@prologic I completely forgot about that topic … 😂🥴