# 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 20
# self = https://watcher.sour.is/conv/ctj6erq
Goryon feature requests!
- edit
- some kind of "you've read up to here" marker
- hide the conversation hash and show some way to get to the yarn
@abucci Yes please! Me too! 👌 @eaplmx Pretty please with sugar on top 🙏 🤗
@abucci Yes please! Me too! 👌 @eaplmx Pretty please with sugar on top 🙏 🤗
I _think_ your "wish list" items are already in the backlog and also on my list of things to do too 👌
I _think_ your "wish list" items are already in the backlog and also on my list of things to do too 👌
@prologic @eaplmx Cool. I will go looking for that once I have a chance to sit at my computer. Our caregiver canceled at the last minute today so I'm watching the baby right now!
@abucci Cool ideas! The You've read up to here is something I use a lot... Thinking on that
Could you please explain more about "hide the conversation hash and show some way to get to the yarn"? 😀
1. What would you show instead of the Hash? I'm thinking of something like "Conversation" "Yarn view" or similar
2. What do you mean by "show some way to get to the yarn"? I think there is a button, below the twt for a conversation, or do I misunderstand something? 🤔
@eaplmx Basically stripping the Hash here 
But maybe this should be done server side in the API? 🤔🤔
@eaplmx Basically stripping the Hash here
But maybe this should be done server side in the API? 🤔🤔
@prologic Got it!
I thought you were saying this one:
Hmmm, good question. I'm aware the hash is part of the twt, but it can be hidden in the App for readability (I'm thinking of a RegEx or something simpler). How would it be if you hide it on the API? 🤔
@eaplmx Let me do some playing around today and see...
@eaplmx Let me do some playing around today and see...
@prologic I think it should be server side, having it handled there greatly help any clients using the API by simply presenting already cleaned data.
Another point that can be included is an pre-compiled markdown content, it would lighten up the burden on the client.
@justamoment I think I agree with you. And by "pre-compiled" do you mean just hand API clients the HTML they _should_ render and do all the rendering work server-side anyway and reuse all the same logic? (_I also think this is better for consistency's sake_)
@justamoment I think I agree with you. And by "pre-compiled" do you mean just hand API clients the HTML they _should_ render and do all the rendering work server-side anyway and reuse all the same logic? (_I also think this is better for consistency's sake_)
@prologic I would vote on preserving the original twt content, but I've been really busy and I haven't thought enough on that to have a strong opinion.
@eaplmx I _think_ we can just provide all variants of the content; We already do anyway. We provide the original twt content and markdown, so no reason we can't add some additional cycles on the server-side / api-side and just do the rendering...
@eaplmx I _think_ we can just provide all variants of the content; We already do anyway. We provide the original twt content and markdown, so no reason we can't add some additional cycles on the server-side / api-side and just do the rendering...
@prologic that's right, if would be great for both client and and compiler. I've seen some build script that convert feed to pages. It can works great there too.