# 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 46
# self = https://watcher.sour.is/conv/eek7qna
I think I’m going to punish feeds that post with time stamps into the future and refuse to ingest their Twts until they are current or in the past. 😁
I think I’m going to punish feeds that post with time stamps into the future and refuse to ingest their Twts until they are current or in the past. 😁
I really can’t think of another valid way to handle misbehaving clients 🤔
I really can’t think of another valid way to handle misbehaving clients 🤔
@prologic I'm not sure I'd even call that punishing, as such. Given the way the future posting clients kind of wreak havoc on the timeline (persistently at the top, etc) your proposed solution just sounds like expected behavour IMO.
@eldersnake I tend to think so too. So that being said I'm adapting the types.SplitTwts() function to return a tuple of Twts, Twts, Twts (future, new, old) and discard anything considered to be in the future and log a warning with the offending feed in case a pod owner/operator is kind enough to spot it and go offer the poor soul some helpful "IT support" 😂
@eldersnake I tend to think so too. So that being said I'm adapting the types.SplitTwts() function to return a tuple of Twts, Twts, Twts (future, new, old) and discard anything considered to be in the future and log a warning with the offending feed in case a pod owner/operator is kind enough to spot it and go offer the poor soul some helpful "IT support" 😂
@prologic Is it really that much of a problem, though? (It would be really funny if *you* introduced a bug now which accidentally drops some twts because something’s “wrong” with their time stamp. 🤣)
@prologic Is it really that much of a problem, though? (It would be really funny if *you* introduced a bug now which accidentally drops some twts because something’s “wrong” with their time stamp. 🤣)
@prologic Is it really that much of a problem, though? (It would be really funny if *you* introduced a bug now which accidentally drops some twts because something’s “wrong” with their time stamp. 🤣)
@movq they will not be dropped. They will simply be "held" in Oblivion, until their time to show has come. That is, until they are now (present) or then (past). 😋
@prologic How are you gonna punish us? Me and @sorenpeter are gonna keep posting in the future for a way to promote upcoming events. I have seen @Devine Lu Linvega been doing the same. I would argue that that client/reader should be able to filter out these future posts into its own list, like we got the timeline and mentions :)
Okay I'm pretty satisified with the changes to types.SplitTwts() and the new tests cases (_there were none before because the function was quite simple before 🤣_):\n\n 
Okay I'm pretty satisified with the changes to types.SplitTwts() and the new tests cases (_there were none before because the function was quite simple before 🤣_):
Okay I'm pretty satisified with the changes to types.SplitTwts() and the new tests cases (_there were none before because the function was quite simple before 🤣_):
@movq This is happening in a "group"(ing) function that determines which parts of a feed are considered "new" and which parts are considered "old". This determines yarnd's behaviour of when to moves twts out of the active in-memory cache and to the on-disk archive. The change here would simply be to also consider twts in the future and ignore them until they become "relevant" 😂
@movq This is happening in a "group"(ing) function that determines which parts of a feed are considered "new" and which parts are considered "old". This determines yarnd's behaviour of when to moves twts out of the active in-memory cache and to the on-disk archive. The change here would simply be to also consider twts in the future and ignore them until they become "relevant" 😂
@darch \n> are gonna keep posting in the future for a way to promote upcoming events.\n\nRight, but Yarn users will not see them until their time has come. So, the promotion piece will not work, at least on Yarn.
@darch LOL! 🤣 I wasn't sure this was you until you chimed in 😂 "punish" wasn't the right word, sorry, I apologize, but as @eldersnake rightfult pointed out, it's not really "punishing". The problem you've now introduced is the one and only **valid** use-case for such twts with a "future" timestamp. I'm not really sure how to deal with this though (_at least not right now_). I'm open to ideas. cc @lyse as the official spec writer 😅
@darch LOL! 🤣 I wasn't sure this was you until you chimed in 😂 "punish" wasn't the right word, sorry, I apologize, but as @eldersnake rightfult pointed out, it's not really "punishing". The problem you've now introduced is the one and only **valid** use-case for such twts with a "future" timestamp. I'm not really sure how to deal with this though (_at least not right now_). I'm open to ideas. cc @lyse as the official spec writer 😅
@fastidious @darch
> are gonna keep posting in the future for a way to promote upcoming events.
>
> > Right, but Yarn users will not see them until their time has come. So, the promotion piece will not work, at least on Yarn.
The _problem_ I have is that I _kind of_ tend to find this an abuse of the "system" so to speak. You can effectively put something in someone's face for hours/days on end by just abusing the fact you can write an entry in your feed with any arbitrary timestamp. Yes, the spec allows for this, but...
@fastidious @darch\n\n> are gonna keep posting in the future for a way to promote upcoming events.\n>\n> > Right, but Yarn users will not see them until their time has come. So, the promotion piece will not work, at least on Yarn.\n\nThe _problem_ I have is that I _kind of_ tend to find this an abuse of the "system" so to speak. You can effectively put something in someone's face for hours/days on end by just abusing the fact you can write an entry in your feed with any arbitrary timestamp. Yes, the spec allows for this, but...
@fastidious @darch
> are gonna keep posting in the future for a way to promote upcoming events.
>
> > Right, but Yarn users will not see them until their time has come. So, the promotion piece will not work, at least on Yarn.
The _problem_ I have is that I _kind of_ tend to find this an abuse of the "system" so to speak. You can effectively put something in someone's face for hours/days on end by just abusing the fact you can write an entry in your feed with any arbitrary timestamp. Yes, the spec allows for this, but...
@prologic \n> I kind of tend to find this an abuse of the “system”\n\nIt is an abuse, of course. Because of the way twtxt works, and Yarn's discovery in particular, a future twt remains on top until it isn't.
This can be done simple by putting them in a detail/summary html-tag
This can be done simple by putting them in a detail/summary html-tag\n
@darch not interested. I vote no.
@prologic That kinda ruins the fun time travel mystery. 😂 But on a serious note, couldn't they just be cached with the time they get loaded at or something? 🤔
@fastidious Oh, so we have scheduled posting features now, except the fact they're just kinda accidental, rather than planned. 😄
@thecanine I'll defer to @lyse or @movq why we just don't do that. My instinct however tells me that broken/misbehaving clients should just be fixed, and it's probably better to just ignore them in this way (_maybe_) until the timestamp _actually_ makes sense.
@thecanine I'll defer to @lyse or @movq why we just don't do that. My instinct however tells me that broken/misbehaving clients should just be fixed, and it's probably better to just ignore them in this way (_maybe_) until the timestamp _actually_ makes sense.
@prologic Maybe you could do some kind of a compromise and put them on top of the users profile, but not the timeline visible by everyone, kind of like a timedbpin Tweet, so one could at least somewhat promote future stuff. 🤔
@thecanine No we don't. But if you _really_ want "scheduled" posts that _can_ be a feature of yarnd and the Mobile App. That has nothing to do with any specs or protocol level interactions, so I'm fine with that, That's more of a UX (_User Experience_).
@thecanine No we don't. But if you _really_ want "scheduled" posts that _can_ be a feature of yarnd and the Mobile App. That has nothing to do with any specs or protocol level interactions, so I'm fine with that, That's more of a UX (_User Experience_).
@thecanine I _think_ lists are a better way to handle this type of thing more generically. And that's something I want to explore. Bookmarks are already proving that. I just need to build a few data structures and make "lists" a proper thing.
@thecanine I _think_ lists are a better way to handle this type of thing more generically. And that's something I want to explore. Bookmarks are already proving that. I just need to build a few data structures and make "lists" a proper thing.
Also... Speaking of which... yarnd has always had (_from early on_) "Feeds" or "Personas". I use them a fair bit, and these are also the @news @support and @help feeds that you see here and many current pod owner/operators are familiar with already. The basic idea here is that you can create different "personas" to "post as". It's actually a _really_ useful way to segregate content you're interested in publishing. I use this to write about @rocknswap (_watch for this tomorrow!_) @astrophotography (_when I actually pull my telescope out_) and @home_datacenter
Also... Speaking of which... yarnd has always had (_from early on_) "Feeds" or "Personas". I use them a fair bit, and these are also the @news @support and @help feeds that you see here and many current pod owner/operators are familiar with already. The basic idea here is that you can create different "personas" to "post as". It's actually a _really_ useful way to segregate content you're interested in publishing. I use this to write about @rocknswap (_watch for this tomorrow!_) @astrophotography (_when I actually pull my telescope out_) and @home_datacenter
@prologic Yeah, guess that could be one of the very low priority features, but I don't know how useful it'd be here, as it's mostly used to farm likes and shares by posting in the time where the big accounts following you are active, hoping they see, share and make it blow up.
With like/share farming not being possible here, I don't know if I'd ever use it, when I don't even use it on the platforms where both of those things can already be done. 😄
@prologic Yeah, guess that could be one of the very low priority features, but I don't know how useful it'd be here, as it's mostly used to farm likes and shares by posting in the time where the big accounts following you are active, hoping they see, share and make it blow up.\nWith like/share farming not being possible here, I don't know if I'd ever use it, when I don't even use it on the platforms where both of those things can already be done. 😄
