jprjr_

Going with UTC doesn't work all that well.

Time zones give a rough idea of where the sun is and whether people are more likely to be asleep or not.

Like I know if I schedule a meeting at 8am in New York, that's 5am in California so I'm unlikely get people from California to attend. Or at least it's pretty rude of me to expect people in California to attend

If I schedule a meeting at 12 UTC - that gives no indication of where the sun is in New York or California (or anywhere).

The fact is people tend to do things with the sun is up and sleep when it's down. Time zones are a compromise so your clock is still kind of in sync with the sun while still being able to synchronize with larger areas.

I'm thinking of a time I worked a university help desk and had to deal with a professor that considered himself a night owl and didn't understand why we weren't staffed during his preferred working hours of 10pm-8am. He was literally the only one on campus working those hours, besides things like security.

There's wanting to work a bit earlier or a bit later than everyone around you but there's a limit to how out-of-sync you can get.

I'd imagine the choice is driven by a whole lot of factors like which is the busier airport. It's probably easier to adjust the Cuba departure than the Miami arrival.

It's kind of like how some parts of the country should really be in a different time zone but they keep in sync with a nearby, bigger city. I'd imagine the smaller airports/airlines just say "yeah your Cuba flight is leaving an hour later so we stay in sync with Miami"

In the US we switch between "(zone) standard time" to "(zone) daylight time" - Eastern Standard Time to Eastern Daylight Time.

So "permanent daylight saving time" makes sense to us since we use the term "daylight time" where Europeans tend to call it "summer time."

Still true that DST really just describes the overall time-changing process, just giving some insight into why the phrase makes sense to us.

Feel like there's a few parts missing that I'm not getting.

The author mentions that the PS5 uses RTMPS to push video up to twitch - but suddenly it just uses plain RTMP?

let's say you have a bug that makes your app unusable. If you can't get an update our for a week - people are going to just stop using your app.

F-droid is the biggest one

Yes and no.

The computer itself won't really do anything. But I'm sure suicides go up when people lose all their money, or get personal private details leaked, and so on.

My experience isn't that they're not being told. It's that they just don't care.

Sorry but I just fundamentally disagree about the app centralization.

If you want xmpp to gain traction you need an app that exists on both mobile platforms. It can (and should) have per-platform tweaks and everything to be performant. But a person needs to be able to just tell their friend a single app, they need to be able to find it in their app store.

The question is "how does xmpp gain traction?" and the answer is having a single flagship app that runs on everything.

For me searching my old messages is really useful. I don't scroll back through history but I'll search for things like "plumber" to find the number of a plumber a friend texted me a while back.

Pretty certain pidgin relies on gtk2 which is pretty dead. Most of the supported protocols are also dead, or woefully outdated like XMPP and IRC.

They've been working on a version 3 for years but no idea if that will ever happen.

Plus the sad reality is even if they're not using Chrome they're probably still using Chrome - most browsers are based on Chromium. You have Safari and Firefox, nearly everything else is just Chrome.

Also last I checked - on iOS devices even if you use Chrome, you're really using Safari - I believe apple forces all web content to be rendered using the built-in WebKit.

For email - most people use the official app and assume they have to use it.

You sign up for Gmail, you get the Gmail app. You sign up for Outlook, you get the Outlook app. 1 service = 1 app.

For browser - on mobile most people use whatever the default browser on their device is. On desktop - Chrome. Pretty much everybody just downloads and uses Chrome.

Re: fediverse my point is - regular people just do not care about any of the fediverse-y parts of it. If I share a post I saw, I don't say "here's a thing I saw on the fediverse" - I just say "here's a thing I saw on Mastodon."

Plus the reality of the fediverse is if you want to use multiple platforms, you wind up needing multiple accounts anyway. Like if I want to upload to Peertube, I need to make a Peertube account, so we're back to where we started of having multiple places to follow people since I can't use my Mastodon account to upload to Peertube. I'm able to have some cross-platform interaction, like commenting on videos from mastodon - but there's issues there like, Pixelfed only showing people posts with images.

When talking to most people I just call the whole thing Mastodon and treat it like its a single app/service, because that's what people are used to. If I start trying to tout how the fediverse is a decentralized platform of multiple applications and you can kinda/sorta interact across platforms - people's eyes glaze right over. They just do not care.

For apps - I've never met a person that picks a messenger because its tweaked for their platform. They just prefer whatever their friends are on. iMessage is something of a odd case since Apple just rolls you into it automatically and presents it via the default app.

There is a XEP for it but as per usual, it's experimental and not widely implemented: https://xmpp.org/extensions/xep-0513.html

https://xmpp.org/software/?category=clients&xeps=0513

Make a single cross-platform client that implements every non-humorous XEP. If you tell people "on Android you should use this app, on iOS use that app" - you lose regular people fast. If you have a feature that only exists in one app on one platform, you also really lose people.

People don't really sign up for protocols, they download apps. Like I often refer to the fediverse as "Mastodon" even though I know that's not entirely correct, because it's the fastest, easiest way to communicate what I'm talking about - microblogging. So you really need a single, good app you can just tell people to download.

Nothing else, I think what the're more concerned with is how open an architecture is.

I think with RISC-V if you wanted to design your own chips and stuff you can just do it, whereas ARM doesn't let you do that.

I'm not about to build my own chips so it doesn't matter all that much to me but I understand where the person is coming from. They'd rather write assembly for the more open architecture.

You could argue well, if you have to open the file to read it anyway may as well look for magic numbers.

That doesn't work well with text documents which won't have any kind of magic number. So now you're doing some heuristics to determine is this text/plain, text/html, text/svg? You're pretty much just guessing at that point.

A good number of file formats out there are just Zip files with a particular structure. JAR files, docx - so relying on magic numbers doesn't really work for those, either.

Also to service a HEAD request you'd have to open the file and read a few bytes that you just discard.

If you just do it by extensions you don't need to read files at all or perform heuristics, and no ambiguity for what mimetypes to use for text documents, zip-based formats, etc.

Honestly requiring DMARC was overall a good thing.

I was an email admin for a university. In the past - each college ran their own email. Before DKIM, before SPF, you'd just have basically random servers on the internet sending email as (school).edu. Tons of random subdomains too. math.(school).edu and so on.

Email was eventually centralized but you'd have parts of the university still running their own things. Insisting they're special and can't be brought into the fold.

So, we had a lot of stuff out there just not passing authentication. A lot of spammers could just impersonate our domain.

We'd go to leadership and say "hey we should really get our act together" - but everything was working. Our emails were still getting out. Hard to justify spending the time, getting various higher-ups within departments to give up their things, and so on.

Unless you can get like, the president to back your initiative- universities are very decentralized and it becomes an issue of "do we have the political capital to spend here." The overall relationship between central IT and the various college-based IT departments was terrible, often bordering on combative.

Google and Yahoo made it so we could go to leadership and say "people will not get our emails if we don't get this straightened out" and it became a priority. When I left our DMARC reports were showing something like a 99% pass rate when it was previously like, 50.

So, I'm glad Google and Yahoo made that call, it gave us the kick in the pants we needed to get our own shit together. I am 100% certain we were not the only org like this.

Plus for a small host - where you're just running a single mail server or something - you just need a few things to pass DMARC.

A DMARC record, and an SPF record, and for your emails to pass SPF. You technically don't need to do DKIM signing (though I'd still recommend it because that survives automated forwarding).

Just a few years ago, Atlassian required you to add an unnecessary include: record to your SPF record, and wouldn't use your domain for emails until they scanned your SPF record for that include. https://jira.atlassian.com/browse/AX-1477

You'd think companies generating as much email as Atlassian would know what they're doing.

Lookalike domains are a problem but in my opinion the bigger problem is when attackers figure out how to hijack a real domain.

For example, making a company named "there's a problem with your account call this number" on a site like PayPal and getting it to generate emails. They'll be from actual paypal.com and pass all authentication.

The other issue I'll often see is subdomain takeovers. Company makes a subdomain a CNAME to some other, external domain. Usually with the intention of hosting a webpage externally or whatever.

That other domain expires, but the CNAME doesn't. Somebody buys up the external domain, now they can publish SPF records and pass DMARC relaxed alignment on the organizational domain.

Now you can send all the emails you want with literally anything you'd like and the providers will say "yep, this passed DMARC."

That was how I felt. "The Future of Email", from Fastmail - I immediately assumed some big announcement.

It's basically "you need to pass DMARC now" which has been true for 2 years.

It also goes into how authentication helps stop spoofed domains which yes, is true. But in my opinion the biggest problem isn't spoofed domains at all.

Attackers will figure out how to make your payment platform (PayPal, Stripe, etc) send out emails. They'll figure out what pieces of info make it into the generated emails, so they'll do things like set their company name to "there's a problem call this phone number." So next thing you know you're getting an email from PayPal that sounds urgent because they'll put that company name in the subject or body of the email.

These emails will be legit, from-the-actual-company, passes-all-authentication emails. DMARC can't catch that, and that's what I've been observing attackers do. They'll find a ticketing system or payment processor and get them to generate "authentic" emails.

I was sincerely hoping that Fastmail had something to deal with that problem.

> They're widely understood

I'll tell you right now, I've had multiple cases where I've had to quote parts of the RFCs to large companies because they were handling email authentication incorrectly.

They are wildly misunderstood. The moment I see "add this include: directive to your SPF record" in some marketing platform's integration documentation I know they're going to fuck something up.

To add-on, the really pro move is to not touch the client's SPF record at all. Use your own domain in the SMTP envelope and have SPF be valid for that. Just have the client establish DKIM records and use DKIM, and only DKIM, to pass DMARC.

If you insist on using the client domain in the envelope, make it a subdomain with MX records back to your infrastructure (so you can track bounces). That will pass relaxed alignment - or just use a subdomain in the from and now you're passing strict alignment as well.

Most companies have no idea how the envelope domain impacts bounces and frankly, doesn't care about tracking them.

A shockingly high number of companies have no idea of the concept of the envelope address.

Restricted access, yes but I'd argue intelligence, tech-savvy, and common sense aren't really the same thing.

There's two big issues I saw on a large University network (talking something like 60k users).

Issue one was account compromises. I cannot tell you how many times faculty, staff, and students would get emails that were clearly phishing and fall for it. Things like, filling out a Google Form with their username and password, despite literally every Google Form saying "never ever put your password in these things."

So then you pair this with universities offering web hosting for students and stuff, and now you've got a bunch of porn being served from your school's web servers because you've got students with no idea how email and phishing work being given university email addresses.

Issue two is their decentralized nature. You'll have some person you've never heard of pop up and say "I run a lab, can I get ailab.(university).edu to point to (university)ailab.com?"

You can try to throw up some road blocks and hassle the user about "why did you do all this and not come to IT sooner, we can host a website for your lab, we have branding guidelines you need to meet to use our domain." Then feathers start getting ruffled, jimmies get rustled, people start flexing about the grant money they pull in, deans get involved, and next thing you know, you're making a CNAME to an off-site domain that you'll never get real control over.

Then that professor or whoever leaves, that pet project of theirs goes away, that off-site domain expires, scammers buy it up and now you've got porn from off-site webservers but using your own domain.

People can be intelligent enough to push our knowledge boundaries into new frontiers, but not have enough common sense or tech-savvy to reach out to IT before setting up a website for their lab.

I have better hopes of social media sites keeping porn out because you can't have dick-measuring contests about the millions of dollars of research grants you're pulling in and get exemptions to policies. They just take the porn off and tell you no, you can't do that.

Regarding SFUs - with something like HLS, I can really easily scale up using something like a caching CDN (not entirely sure if that's the right term). But the idea goes: I can distribute the HLS media playlist, and have my media segment entries prefixed with a caching/CDN service. The service will be configured with the actual origin server, and when a segment isn't in the CDN, the CDN fetches from the origin, on-demand. That was a nice option when I was doing owncast streaming since I really only paid based on viewership, and just had to make sure I had the correct cache-related headers on my media segments.

Or alternatively - I can push media segments up to a CDN and distribute that way, using an s3-compatible service, or just rsyncing to a server with better bandwidth, etc. One thing I didn't care for - again back when I was broadcasting with Owncast - was that I needed to make sure old media segments were expired, otherwise I would rack up an insane bill. I had a 24/7 owncast stream and if you're not on top of expiring media segments with your CDN, it gets expensive fast.

The overall idea is - serving HLS is ultimately serving files and there's a good amount of tooling for that, right.

Now that you mention it, I think WHIP/WHEP can solve some of that. I just don't know of any service where I can have that same cache/CDN-like experience, of either having the CDN connect to the origin as needed and fan-out, or where I can push up and let the service distribute. (though - now I'm googling for "webrtc sfu as a service" and see that is a thing!).

Didn't know about the playout delay extension.

Whether capturing individual audio is easier with RtpTransport or insertable streams - I'm unsure. Possibly? I just figure since MoQ is going to rely on things like WebCodec/WebAudio there's hopefully a bit more control over what happens with audio as it comes in.

I'll admit though - I've started noticing how often podcasts are clearly recorded using something that doesn't allow per-participant recordings and, I'm guessing as long as the quality is good enough most aren't worrying about it.

EDIT: feel like I should mention Pion rules, I used it a few years ago to put together an SRT-to-WebRTC thing and RTMP-to-WebRTC thing to use with Janus Gateway, it was so easy.

There's a few cases where WebRTC falls apart that I think MoQ could help with.

It doesn't work so well for having a low-latency broadcast. Your choices right now are - use WebRTC and deploy selective forwarding units, which are going to be something custom, and likely involve spinning up a bunch of geographically-distributed virtual machines, figuring out signalling and whatnot. Or - use HLS so you can use more standard HTTP CDN tech, but you gain orders of magnitude of latency.

MoQ should allow for a standardized CDN stack, meaning we should be able to have a more abstract service (instead of spinning up VMs, you just employ some company's CDN service and tell it where to get media from).

There's a lot of other little issues with WebRTC for certain, specific applications. Like - last I tried it, browsers will subtly speed up audio/video to keep everything in sync, and you can have scenarios where you'd rather just let the viewer fall behind a bit and skip ahead later (say you're listening to music, speeding it up isn't ideal).

Or - say you want to have a group call and capture each participant's audio individually and edit it together later for something like a podcast. It's been a while since I've tried this, but I recall it being pretty difficult to do that with WebRTC. I remember all the mixing would happen in the browser's libwebrtc and I had really limited control over things.

Universities are so tricky. If you put up too many roadblocks you wind up with official shit on completely external resources. Which makes it hard to figure out what's legitimate and what's a scam.

But make it too easy, you wind up with CNAMEs to external domains, that expire, get bought and now you have scams running on your .edu.

You just don't have the same ability to do top-down management and requirements that you do with the private sector. Individual researchers will get grants and really drive how things need to get done because they're the ones bringing money in.

The answer is yes, to all of it.

Email providers have better spam filtering, some have strict rules about attaching any kind of executable code to an email (as in - you just can't).

Email clients are always getting updated, stricter about validating content before showing it, etc.

To be fair that seems to be the path email is going down. Most businesses don't want run their own email and just use one of two big providers.