# 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 28
# self = https://watcher.sour.is/conv/ftzplka
Just want to put something out there to all you existing pod owner/operators and the Yarn.social community. We (Yarn.social pods) **do not** store any kind of PII about users on pods. We don't even store the email address used for password recovery. That being said however, I'd like to propose two additional fields on the User data model:
- LastLoggedInAt -- A UNIX timestamp of when the user last logged in to their account.
- LastUpdatedAt -- A UNIX timestamp of when the user's account/profile was last updated.
Are we _okay_ with this? π€ ...
Just want to put something out there to all you existing pod owner/operators and the Yarn.social community. We (Yarn.social pods) **do not** store any kind of PII about users on pods. We don't even store the email address used for password recovery. That being said however, I'd like to propose two additional fields on the User data model:
- LastLoggedInAt -- A UNIX timestamp of when the user last logged in to their account.
- LastUpdatedAt -- A UNIX timestamp of when the user's account/profile was last updated.
Are we _okay_ with this? π€ ...
The use-case here would be to provide to Pod owner/operators a way to manage users on their pods better as well as to determine "dead/inactive accounts" and clean them up periodically. I also _believe_ (and $kt84 agreess) that Yarn.social as a "whole" has grown large enough to a point where I can _probably_ think about nuking any old/dead/inactive accounts on my own pod at twtxt.net π
The use-case here would be to provide to Pod owner/operators a way to manage users on their pods better as well as to determine "dead/inactive accounts" and clean them up periodically. I also _believe_ (and $kt84 agreess) that Yarn.social as a "whole" has grown large enough to a point where I can _probably_ think about nuking any old/dead/inactive accounts on my own pod at twtxt.net π
Yeah can't see any issues with that.
@prologic To further lift the protection standard here the timestamp just needs to be date, no need for time granularity. For your outlined use case even a calendar week should suffice.
@lyse Interesting viewpoint there π€ Does it _really_ matter if it's just a time.Time field (Go)? π€ If we're that worried, I _could_ just store a string, with a finite set of values like: "never", "a short time ago", "a while ago", "a long time ago" π
@lyse Interesting viewpoint there π€ Does it _really_ matter if it's just a time.Time field (Go)? π€ If we're that worried, I _could_ just store a string, with a finite set of values like: "never", "a short time ago", "a while ago", "a long time ago" π
@prologic If yarnd takes data protection and privacy seriously, then yes, I'd say it matters. Not sure how the transition between "a short time ago", "a while ago" and "a long time ago" can be implemented, though. But that would be the coolest thing, I agree. :-)
@prologic I don't mind what @lyse is saying here, TBH. There's probably an argument to be made that such time granularity down to the millisecond _could_ act as a useful piece of metadata, to those that we would rather it not. A bad actor, I suppose, could use it to further gauge a person's habits, how often they log in on their device, etc. It might sound tin foil hat, but in this day and age...
Exactly, @eldersnake, you've managed what I failed at β to extract the important bits from my brain. :-) Granted, the posted messages themselves give away much more and if operators really want to get more insight, they can just look at the access logs or even maintain their own fork. But I strongly believe that the less data one gathers, the better. If there is a trough, pigs will come.
@eldersnake Nope nope I _actually_ happen to agree, which is why I've brought this up for discussion. The use-case is primarily to prune inactive/dead accounts. That's it, so in that sense, a granularity of a day ie probably **more than enough** right?
@eldersnake Nope nope I _actually_ happen to agree, which is why I've brought this up for discussion. The use-case is primarily to prune inactive/dead accounts. That's it, so in that sense, a granularity of a day ie probably **more than enough** right?
And to be honest, I'm not sure the UpdatedAt timestamp is needed, I'm not even sure why I mentioned it (_out of habit I suppose_) -- So just LastLoggedInAt.
And to be honest, I'm not sure the UpdatedAt timestamp is needed, I'm not even sure why I mentioned it (_out of habit I suppose_) -- So just LastLoggedInAt.
@prologic Oh yeah, I reckon a day is plenty enough. π
what if it was just a Counter that counted backwards on a daily basis with an automated daily background job? The pod owner/operator could tweak the threshold for deleting any active accounts based on this counter. every time you login or use an API token the counter is reset to zero.
what if it was just a Counter that counted backwards on a daily basis with an automated daily background job? The pod owner/operator could tweak the threshold for deleting any active accounts based on this counter. every time you login or use an API token the counter is reset to zero.
@prologic I like the counter idea. When reconfiguring the duration the counters need to be adjusted by (old_duration - new_duration), too. The counter might have a glitch if a yarnd instance is not running for a day or more. But that's acceptable I reckon, people can't login if the instance is down, so that's fair. ;-) Just be sure to thoroughly test this, destroying data would be bad.
I like this idea, that it'd be something like "not seen for x days", but it'd definitely have to depend on way more stuff than just logging in. As people using the app or some always running browser might not be logging in and out frequently, but still be active on here. π€
@lyse Yeah but I think this would only cleanu old inactive accounts that have never seen any actually use. π
@lyse Yeah but I think this would only cleanu old inactive accounts that have never seen any actually use. π
@thecanine basically the way this would work is anytime thereβs any activity the counter would reset to zero.
@thecanine basically the way this would work is anytime thereβs any activity the counter would reset to zero.