# 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 6
# self = https://watcher.sour.is/conv/d3afhfq
@prologic and any other Golang aficionado... interested in opinions on what is considered best practice here, as I'm still quite green here. So if I have a server and client (both written in Go), data is passed as JSON and marshalled/unmarshalled in both cases to structs that are basically identical between the programs, and I want to have these structs 'shared', should I put the structs maybe into a single file as it's own package and just pull them into the server/client that way?
@eldersnake Yes. Use a separate package. Like what we've done with Yarn and how it depends on the go-types library dor common types:
@eldersnake Yes. Use a separate package. Like what we've done with Yarn and how it depends on the go-types library dor common types:
@eldersnake Yes. Use a separate package. Like what we've done with Yarn and how it depends on the go-types library dor common types:
@eldersnake Yes. Use a separate package. Like what we've done with Yarn and how it depends on the go-types library dor common types: