# 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 29
# self = https://watcher.sour.is/conv/mwhjn4a
@prologic From Russ Cox: "note that if you set GOPROXY=direct, the go command still uses the checksum database to protect against supply chain attacks. If you really want the go command not to use servers, you also need to set GOSUMDB=off."
lol it has no end
@ocdtrekkie I don't have a problem with a central checksum database and service. That's okay really.
@ocdtrekkie I don't have a problem with a central checksum database and service. That's okay really.
@ocdtrekkie I don't have a problem with a central checksum database and service. That's okay really.
@ocdtrekkie I don't have a problem with a central checksum database and service. That's okay really.
@prologic It basically gives them all the same data using GOPROXY does though, does it not?
@prologic What info do they get via GOPROXY but not get through GOSUMDB? They'd get obviously your IP/connection plus all of the packages you are using, no?
@ocdtrekkie Yeah but so what? That's the same as GitHub tracking all the shit you clone 😆
@ocdtrekkie Yeah but so what? That's the same as GitHub tracking all the shit you clone 😆
@ocdtrekkie Yeah but so what? That's the same as GitHub tracking all the shit you clone 😆
@ocdtrekkie Yeah but so what? That's the same as GitHub tracking all the shit you clone 😆
@prologic I mean my point is that people thought they were excluding Google from that info by turning the proxy off, so Google went and implemented another less known switch to get the same data.
@ocdtrekkie I dunno if it really happened that at cynically did it? 🤔
@ocdtrekkie I dunno if it really happened that at cynically did it? 🤔
@ocdtrekkie I dunno if it really happened that at cynically did it? 🤔
@ocdtrekkie I dunno if it really happened that at cynically did it? 🤔
@prologic I mean, from a historical standpoint, probably no, but the fact that there's actually two and now a proposed third variable you have to set to keep Google out of your dev tools is a continuing problem, especially since the second one doesn't seem to be well-known.
@ocdtrekkie Yes but think about it... (not that I'm defending Google™ here), if you were to implement this yourself, you would have to separate out the "fetching a package" vs. "verifying the integrity of a package" right? -- Put another way, you wouldn't trust the checksum/integrity of a package from the source you got the package from (in this case Git) would you? The only wati you _could_ do this is if the checksum was also signed with a key. Even as I write this, I'm not even sure if the GOSUMDB mechanisms can be trusted at all either, as it assumes the "checksums" haven't been tampered with by Google™ themselves, meaning that in a supply-chain-attack, you have to trust Google™ 🤦♂️
@ocdtrekkie Yes but think about it... (not that I'm defending Google™ here), if you were to implement this yourself, you would have to separate out the "fetching a package" vs. "verifying the integrity of a package" right? -- Put another way, you wouldn't trust the checksum/integrity of a package from the source you got the package from (in this case Git) would you? The only wati you _could_ do this is if the checksum was also signed with a key. Even as I write this, I'm not even sure if the GOSUMDB mechanisms can be trusted at all either, as it assumes the "checksums" haven't been tampered with by Google™ themselves, meaning that in a supply-chain-attack, you have to trust Google™ 🤦♂️
@ocdtrekkie Yes but think about it... (not that I'm defending Google™ here), if you were to implement this yourself, you would have to separate out the "fetching a package" vs. "verifying the integrity of a package" right? -- Put another way, you wouldn't trust the checksum/integrity of a package from the source you got the package from (in this case Git) would you? The only wati you _could_ do this is if the checksum was also signed with a key. Even as I write this, I'm not even sure if the GOSUMDB mechanisms can be trusted at all either, as it assumes the "checksums" haven't been tampered with by Google™ themselves, meaning that in a supply-chain-attack, you have to trust Google™ 🤦♂️
@ocdtrekkie Yes but think about it... (not that I'm defending Google™ here), if you were to implement this yourself, you would have to separate out the "fetching a package" vs. "verifying the integrity of a package" right? -- Put another way, you wouldn't trust the checksum/integrity of a package from the source you got the package from (in this case Git) would you? The only wati you _could_ do this is if the checksum was also signed with a key. Even as I write this, I'm not even sure if the GOSUMDB mechanisms can be trusted at all either, as it assumes the "checksums" haven't been tampered with by Google™ themselves, meaning that in a supply-chain-attack, you have to trust Google™ 🤦♂️
I don't trust _any_ public big-tech cloud company as far as I can throw 'em. Apple included.
I don't trust _any_ public big-tech cloud company as far as I can throw 'em. Apple included.
I don't trust _any_ public big-tech cloud company as far as I can throw 'em. Apple included.
I don't trust _any_ public big-tech cloud company as far as I can throw 'em. Apple included.