How have you liked Obsidian? I was going to use it but realized it pay walled sharing notes between devices. Looking into this again - are you self hosting Obsidian via LiveSync plugin?
Except I wanted more security and multiple users. Instead of using the default admin user, I created one user for each person. Done in the "_users" database. Then create one database for each person. Assign each user as a "Member" to their respective database, not admin. Now each person has their own credentials that can access only their database.
Not OP but I'm a very happy longtime Obsidian user. Maybe a little unfair to characterize as "paywalled" given their sync service is optional (and works very well), and a directory of markdown files is about as portable and flexible as it gets for self-hosting.
Banning gambling ads isn’t banning gambling. It’s just stopping corporations from pushing addictive behavior on people who didn’t consent to see it.
We banned cigarette ads for the same reason — harm and addiction.
Limiting corporate ad power protects individual liberty. I can choose to gamble if I want, but I shouldn’t have to fight off brainwashing every time I watch a game.
Keeping the "hard subs" content is a lot of videos as the subtitles were encoded into the video stream.
This makes CDNs and other systems more difficult to utilize because we have a ton of video streams with just caption changes as opposed to just the Japanese audio source + caption files.
It's one of those things that doesn't seem that problematic till you include all the video_qualities to support streaming bandwith. So you also get a #hardSubLanguages * #videoQualities
Obviously you probably thought about it but what about rendering the subtitles on top of the video stream? Was there a reason it was not possible (e.g DRMs?)
This kind of softsubbing is what Crunchyroll primarily does, but it has hardsubbed encodes for devices that cannot do softsubbed rendering of the ASS subtitles that Crunchyroll uses. I go over some ways in how they could do away with these hardsubbed variants in the article without any notable loss in primary experience quality.
I’m pretty sure it’s not too hard to implement an ASS → PNG renderer (especially considering vibe coding is now a thing). Then, just need to split out subs that can be actual text somehow from the ones that have to be overlays.
Apart from that... surely they could at least keep ASS subs for the players that support it, and serve “fallback” subs for low-end devices?
So you make the business decision to stop supporting weird devices that can't do the job right? Why on earth does a cartoon streaming site need provably-correct subtitle support for devices that clearly suck?
If you hardsub the video, then you need to have a full copy of the video for every language. That's the opposite of what people want. They want a single textless video source that can then accommodate any internationalization.
The article claims that you can slice up the video and only use language-specific hardsubs for parts that need it. I'd be interested if there are technical reasons that can't be done.
To be more specific, basically all online streaming today is based around the concept of segmented video (where the video is already split into regular X-second chunks). If you only hardsubbed the typesetting while keeping the dialogue softsubbed (which could then be offered in a simpler subtitle format where necessary), you would only need to have multiple copies of the segments that actually feature typesetting. Then you would just construct multiple playlists that use the correct segment variants, and you could make this work basically everywhere.
You can also use the same kind of segment-based playlist approach on Blu-ray if you wanted to, though theoretically you should be able to use the Blu-ray Picture-in-Picture feature to store the typesetting in a separate partially transparent video stream entirely that is then overlaid on top of the clean video during playback.
It's incredibly fragile at the CDN level if deployed at scale for a start.
You'd see playback issues go up by 1000%.
In the nicest possible way, it is pretty clear that this article was written by somebody who has only ever looked at video distribution as a hobbyist and not deploying it at scale to paying customers who quite reasonably get very upset at things not working reliably.
What would be the problems? When I’ve looked into streaming video before (for normal, non ripping reasons), I’ve noticed that most are already playlists of segments. You’d just need to store the segments that are different between versions, which should be better than keeping full separate versions which is what they apparently do currently.
This is just an excuse. There needs to be a hard english sub and then keep other languages can be single video with different text file. Deleting 80% good things only to keep other 20% happy should not be an excuse.
Only english is the most popular and just keep it. Most of the good hard subs are made for english and that is what people want.
That is exactly what I thought and I am not even a native English speaker. My English is infinitely better than my Japanese though, so if I cared about anime I’d much rather watch a good English version rather than a bad German one
Having worked a long time with client teams as a lead - this is always the biggest pain in the ass.
At one of my last phase startups I started shifting all our business logic stuff into our graphql server and treated it like it was part of the client teams. (we had ios/android/web as independent full apps with a very small team of devs).
Business logic is the real killer. Have one person suck it up and do it in typescript (sorry y'all) on the GQL/apollo server and all the clients can ingest it easy.
Send down viewmodels to the clients not data models. etc etc.
This helped DRAMATICALLY with complexity in the clients.
Has been the true core vision of the web if not mobile. If I remember correctly, that is how the original Basecamp was implemented, or Craigslist (still is?)... or this very website
OP is likely talking about local business logic, ie password field is min 3 chars long. You validate that in the FE before sending it up to get instant feedback to the user.
There are external factors apart from your own API that can impact latency, for example a user could be in an area of poor internet connection or have a slow connection. Users do not live in our perfect development environment bubble where everything just works, it’s important not to assume that.
That's how we got to "download 50 GB before playing a game on a console is fine", feels like we just stopped carying. Sending the form to the BE just to do same basic validation adds so much latency to the UI that it feel unusable for many/most users.
Related: A few Sundays ago I wanted to play Anno again. Sadly it was not installed on the Laptop I used. So i started downloding it because you won't get it on DVD/as iso-file today). Now it's a few Sundays after and I didn't play yet - because the download took 7 hours.
That's such a ridiculous logical falacy. You already have to send the form input to submit the form in the first place and you already need server side validation.
I just checked one of my app's register page (which makes > $2M ARR). If you submit a short password it returns an error from the backend that says "Password should be at least 6 characters.". (It uses Supabase). But yeah, that is so unusable it is basically the same as taking 7 hours to download a game onto your Playstation. Great logic!
And not just off-line, but as we learned last week, if us–east-1 is down you have spotty connectivity, not hard down, and your device needs to not cook your users; literally in the case of Sleep8.
It was a near real-time messaging application. So not really applicable (other than seeing messages you already received - which could be cached from previous sessions).
I guess I'm not clear on what you mean about putting business logic in the client. It can't only be on the client side. If you do so, then obviously you have to replicate it on the server to check that the client was sending the right results, no? Not to mention avoiding thread races and double inserts and whatever else may have gone stale on the server before you allow a client to validate something? Even if your code isn't public-facing, the server still needs to check everything. As a solo dev it seems insane to me to ever put business logic in the client, unless the client and server literally share the same typescript codebase for crosschecking ops, and even then the server needs the same code plus additional safeguards. It baffles me that anyone would write a platform from the ground up with primary business logic on the client side, if the server isn't written in the same language. Maybe some simple initial validations and checks to avoid bombarding the server, but the server has to be the central source of truth.
That’s the exact opposite of what the GP is suggesting. Read this again:
> Business logic is the real killer. Have one person suck it up and do it in typescript (sorry y'all) on the GQL/apollo server and all the clients can ingest it easy.
Move the logic to the GQL retriever so that clients don’t have to implement business logic.
we had a lot of very talented iOS devs that started running away with feature development when the server team couldn't keep up.
This really hurt the android + web client teams.
Eventually our backend started changing (mono-rail -> microservices) and it turned into an absolute cluster of trying to massage/cram new data models into the existing ones the iOS team created.
Late stage startup and then post finding product market fit problems.
OP is likely talking about local business logic, ie password field is min 3 chars long. You validate that in the FE before sending it up to get instant feedback to the user (yes you also have it on the server).
cable companies require poe filters. if they find that there is some "noise" leaking from your house, they may put a big filter of their own outside, that can degrade speed of modem
I used digital ocean for hosting a wordpress blog.
It got attacked pretty regularly.
I would never host an open server from my own home network for sure.
This is the main value add I see in cloud deployments -> os patching, security, trivial stuff I don't want to have to deal with on the regular but it's super important.
Wordpress is just low-hanging fruit for attackers. Ideally the default behavior should be to expose /wp-admin on a completely separate network, behind a VPN, but no one does that, so you have to run fail2ban or similar to stop the flood of /wp-admin/admin.php requests in your logs, and deal with Wordpress CVEs and updates.
More ideal: don't run Wordpress. A static site doesn't execute code on your server and can't be used as an attack vector. They are also perfectly cacheable via your CDN of choice (Cloudflare, whatever).
Yes, but the web server is just reading files from disk and not invoking an application server. So if you keep your web server up to date, you are at a much lesser risk than if you would also have to keep your application + programming environment secure.
That really depends on the web server, and the web app you'd otherwise be writing. If it's a shitty static web server, than a JVM or BEAM based web app might be safer actually.
I think it’s reasonable to understand that nginx/caddy serving static files (or better yet a public s3 bucket doing so) is way, way less of a risk than a dynamic application.
The thing with WordPress is that it increases the attack area using shitty plugins. If I have a WP site, I change wp-config.php with this line:
define( 'DISALLOW_FILE_EDIT', true );
This one config will save you lot of headaches. It will disable any theme/plugin changes from the admin dashboard and ensures that no one can write to the codebase directly unless you have access to the actual server.
How have you liked Obsidian? I was going to use it but realized it pay walled sharing notes between devices. Looking into this again - are you self hosting Obsidian via LiveSync plugin?
Thanks!
reply