Posts by jyasskin@mastodon.social
 (DIR) Post #AP4SLqU9ns71cRnOIS by jyasskin@mastodon.social
       2022-10-29T20:00:07Z
       
       0 likes, 0 repeats
       
       @scottjenson This is an intrinsic problem with federation. And kind of like email, if Mastodon gets actually popular, I expect a few massive servers to win, and have to block most of the rest to protect their users from spam.
       
 (DIR) Post #AP4SLrVbzws0nFU4Ce by jyasskin@mastodon.social
       2022-10-29T20:05:32Z
       
       0 likes, 0 repeats
       
       @scottjenson And how'd that work out for email?I mean, hopefully I'm wrong, but I don't see architectural differences that would change the outcome.
       
 (DIR) Post #AP4SLt7E1aYFmC5cTA by jyasskin@mastodon.social
       2022-10-29T20:31:55Z
       
       0 likes, 0 repeats
       
       @scottjenson This isn't dystopian even if I'm right. It just means #TipYourServer to help them afford their inevitable #TrustAndSafety team.
       
 (DIR) Post #AP4c1YRy9DFvQwjf2e by jyasskin@mastodon.social
       2022-10-29T21:51:02Z
       
       0 likes, 0 repeats
       
       @ondra https://en.wikipedia.org/wiki/Domain_Name_System-based_blocklist and https://mxtoolbox.com/blacklists.aspx describe exactly that kind of blocking. I haven't tried to run my own email, so I can't personally vouch for it being really hard, but it's easy to find stories about it.
       
 (DIR) Post #AP88PYtZvJfNlw1L72 by jyasskin@mastodon.social
       2022-10-29T22:08:11Z
       
       0 likes, 0 repeats
       
       @ellen @scottjenson It's a nice idea, but now imagine you're a country or billionaire trying to get around that ban. You can create new domains faster than volunteer moderators can keep up with, and you can create new accounts on open servers similarly fast.Either this stays niche, or we'll need to pay for moderation teams.
       
 (DIR) Post #AP8C5lL4Li9OODh4CG by jyasskin@mastodon.social
       2022-10-29T17:41:24Z
       
       0 likes, 0 repeats
       
       Over the last week, I proposed a more formal way to describe #time in #WebStandards. I started with https://github.com/whatwg/infra/pull/491, proposing the simplest thing that could possibly work: points in time and lengths of time, borrowing terms from the JS Temporal library: Instants and Durations.The reviewers argued that we should have specs be consistent with the mechanisms in https://w3c.github.io/hr-time/... 1/7
       
 (DIR) Post #AP8C5lkEq8HdeHTAQa by jyasskin@mastodon.social
       2022-10-29T17:41:56Z
       
       0 likes, 0 repeats
       
       https://w3c.github.io/hr-time/ currently expresses time in ms-since-something-vague-but-the-Unix-epoch-in-practice or ms-since-navigation-start, both sharing a type of DOMHighResTimeStamp with other durations. Its algorithms for other specs to use are also confusing, reflecting the fact that it grew over time. E.g. the "current high resolution time" is ms-since-navigation-start, but the "shared current time" is ms-since-the-epoch. (They have the same resolution.) 2/7
       
 (DIR) Post #AP8C5mEj0mfbApjVwm by jyasskin@mastodon.social
       2022-10-29T17:42:17Z
       
       0 likes, 0 repeats
       
       So I rewrote the system by simplifying some lessons I learned discussing the C++ <chrono> library. I suggest we have 2 "clocks" on the web platform: the wall clock, which is what Date uses to match human time, and the monotonic clock, which is what performance measurement and some other uses need to ignore users resetting their clocks and time slew from NTP and leap seconds. 3/7
       
 (DIR) Post #AP8C5mh5JLM4an0A9Q by jyasskin@mastodon.social
       2022-10-29T17:42:42Z
       
       0 likes, 0 repeats
       
       Both clocks have their own kind of instant, which has been renamed to "moment" to make a reviewer happy. These can be unsafe and precise or safe-for-#Spectre and coarse. Durations are shared and always coarse, which makes it possible to approximately transfer moments from one clock to another. 4/7
       
 (DIR) Post #AP8C5n9Rbu2Y0kGoM4 by jyasskin@mastodon.social
       2022-10-29T17:42:58Z
       
       0 likes, 0 repeats
       
       Specs have 3 ways to create times: the "current wall time", the "current monotonic time", and the "current relative timestamp". That last is the way to get at the common ms-since-navigation-start measurement that's directly useful to Javascript. The others have to be explicitly converted to a duration (or Date for wall times) before they're given to JS. Check out the full proposal at https://github.com/w3c/hr-time/pull/140. 5/7
       
 (DIR) Post #AP8C5wCbxUvA5Aoy2a by jyasskin@mastodon.social
       2022-10-29T17:43:25Z
       
       0 likes, 0 repeats
       
       This intentionally ignores wall time details like UTC vs UT1–4 vs TAI and the treatment of leap seconds. It also doesn't yet fix problems with the monotonic clock around how it's affected by time slew and system sleep. We'll also have to rethink it once travel at relativistic speeds becomes common or if our #Spectre mitigations ever get good enough to allow resolutions fine enough to notice that a single computer's CPUs can have different speed clocks. 6/7
       
 (DIR) Post #AP8C5xnW1m2F1v5xCa by jyasskin@mastodon.social
       2022-10-29T17:43:39Z
       
       0 likes, 0 repeats
       
       Let me know what you think, and remember to #TipYourServer. (https://patreon.com/mastodon for mine) 7/7