ryan29

GP is referring to the registry, not the registrar. There's lots of competition between registrars, but the registries have a post-sale monopoly on all domains.

Put another way, as soon as you register a .com domain, the only registry that can sell you a renewal is Verisign. If there weren't price controls, Verisign could increase the price of a .com renewal to $100 and there's nothing anyone could do but pay it.

This whole thread back to the root is right. Verisign has a monopoly, you can never drop a domain once it's associated with your business, and all of it should be regulated like a monopoly.

I wonder how far those rules from Apple go.

I don't know a ton about Patreon, but what if creators have exclusive content available via the app and use that to encourage fans to subscribe outside of iOS? What if creators start an education campaign on YouTube telling their fans to avoid subscriptions on iOS?

I wonder if Apple is playing with fire on this one. If the creator and influencer markets turn on them, I think it could have a non-trivial impact on Apple's brand, especially with younger generations. Many modern creators are also smart business people and they're not going to see much value in Apple taking 30% of their revenue when Patreon is already providing all the services they need for about 15% at the top end IIRC.

Right now I think the biggest change that could help the average consumer would be for legislators to allow, or maybe even require, app owners to split platform fees into separate line items. For example, something like:

    Donation              $1.00
    Patreon Platform Fee  $1.18
    Apple Platform Fee    $0.50
    ----------------------------
    Total                 $1.68

How do they deal with the taxes?

The registrars play an important role in terms of services and support. As soon as you register a domain, the registry for the TLD gains monopoly power over you. That doesn’t create any incentive to provide good services or support.

Registrars have to compete in those areas and that benefits registrants. Instead of eliminating registrars I think they need to be empowered a bit at the expense of the registries. The registries don’t seem to understand the product they’re selling and only seem to care about price discovery and discrimination.

I think it can make sense for smaller companies as long as the costs aren't unbearable. There's value in being your own registry operator, especially when it comes to stuff like intellectual property claims, etc..

By being a registry instead of a registrant you get an extra layer of protection that helps to ensure your domain is untouchable. I think it makes a lot of sense to use for long term infrastructure if, again, the costs aren't prohibitive.

They criticize Namecheap for being slow, but is 1 day slow? Who here would pull the plug on a domain relied on by hundreds of thousands of sites faster than that? I get the desire to shut it down instantly, but do we really want registrars taking domains offline in less than a day?

There’s got to be significant liability concerns when you’re doing something that could impact hundreds of thousands of sites. It’s kind of a tough spot to be in, isn’t it?

The same concept should be applied to container based build pipelines too. Instead of pulling dependencies from a CDN or a pull through cache, build them into a container and use that until you're ready to upgrade dependencies.

It's harder, but creates a clear boundary for updating dependencies. It also makes builds faster and makes old builds more reproducible since building an old version of your code becomes as simple as using the builder image from that point in time.

Here's a nice example [1] using Java.

1. https://phauer.com/2019/no-fat-jar-in-docker-image/

The problem with app stores is that they sell the idea of verifying trustworthiness when the really can't. The biggest effect they can have is by doing identity verification and they make the same mistake that EV TLS certificates, etc. did. That mistake is assuming business names and trademarks are unique. They're not.

The entire software distribution industry could use a mulligan. I think it should start by using domains as identity because it's the only namespace we have with global buy-in and anyone can register / reserve a unique identifier (aka domain) in that system.

If the supply chain for that app went back to 'lastpass.com', and that information was prominently displayed, it solves a lot of problems in terms of educating users to help them avoid scams.

This is pretty much the exact stack I've been wanting to try for a while. Being able to spin up a working starter project will be immensely useful, even if I end up doing my own from scratch eventually.

Thanks for publishing this!

Microsoft is betraying user trust with their Windows strategy. A lot of people trust Microsoft, but I wonder if there's a critical mass where the narrative switches to one where the default for most people is to distrust them.

Their products behave too similar to those of bad actors. Recently I had a relative over and was helping them with some computer stuff. They had an odd PDF viewer on their laptop and, when I asked them about it, they called it Adobe. It was not Adobe Reader.

I assumed it was the result of clicking through a paid search result and installing something from the internet, but they insisted they got it from Microsoft. I was confused for a while because it wasn't an app from the Microsoft Store.

Then they explained to me how they got it. They clicked on start, searched for "PDF", and "installed Adobe Reader from Microsoft". The icon for the app they had was obviously made to look similar to Adobe Reader and they had no idea the start menu search is a free for all of Bing results.

They're not stupid and I can't really blame them for misunderstanding. When they showed me, I could see how it would be reasonable to mistake the search result (or ad?) for an app recommendation. The result had an icon and everything. The weird thing is that I can't reproduce it on my PC. I don't get the same results that look too much like recommendations, so either I'm on a different release cadence for Windows or I've disabled some of those unwanted features.

The user should be able to trust everything in the OS. A built-in search feature that exposes users to bad actors is extremely frustrating to see.

A lot of the criticism seems to be about the UI and the site is about functionality that's available. It doesn't make sense to criticize the implementation details in my opinion.

It's disappointing because this site was one of the rare occasions I emailed the link to myself so I can add it to my list of things I want to look at. Having a concise demo of PWA functionality that exists is very useful.

Is there any value in buying a short domain to use with a custom URL shortner? I have an 8 letter .com along with the .net, .org, etc.. There’s a 4 letter domain on a ccTLD that I could buy aftermarket. Ex:

    bluegoat.com
    goat.tt

It’s the same price as renewing my domain on the 10 most popular TLDs for 8-10 years. My gut tells me it’s a waste of money and that I’m better off using one of my current domains (ex: bluegoat.io) if I ever have a need for a custom link shortener.

Does anyone have any insight they could share?

I think the domain validated handles on Bluesky are a big deal. They help reduce impersonation and let you build a reputation around an identity that isn't controlled by the platform.

No one can squat on your handle and, even though you don't technically own a domain, you get a lot more protections with a domain name than you do with a platform based handle. It's much harder to revoke a domain than it is for someone to kick you off their platform.

Some snippets from the FAQ [1].

> The public key is stored on the website and the private key is stored on your device or in your passkey provider, e.g. your Bitwarden Vault.

> Passkeys are often able to sync across your devices, however not all platforms support this yet.

So it sounds like it's not stored in hardware. It'll be interesting to see how it works if solutions that use a TPM or similar start to emerge. I have nearly 1000 passwords and many of them are shared with colleagues, parents, siblings, etc.. I can't even imagine a way you could make that work if the private key is owned by a TPM (aka a hardware bound key) and needs to be enrolled somehow prior to becoming usable.

What happens if I have 500 passkeys backed by keys in a TPM and I get a new computer?

1. https://bitwarden.com/resources/passkeys-faq/

They added boot environments to pfSense+. I think they use ZFS snapshots. You can take a snapshot, set it as the default boot environment, do some updates, and if things go bad you can reboot to get back to the snapshot you set as the default.

I’d like to see some kind of more resilient upgrade process where a pre-upgrade snapshot is taken, the firewall updates and reboots, some kind of watchdog tries to hit a well known endpoint, and the whole thing automatically rolls back to the known good config if it goes X minutes without being able to connect after the update. That would mitigate the riskiest part of updating remotely.

As for new features, once you have a reliable firewall, what more do you want? I wouldn’t complain about a better traffic shaper experience, but OpnSense did that and the “easier” traffic shaper in OpnSense isn’t as flexible IIRC.

For licensing, I don’t hate the TAC-Lite approach. They could make it more clear it’s a lifetime thing (I hope I’m right about that) and I hate begging for installers, but at least they aren’t forcing subscriptions yet. I fear that’s coming one day since it would force us to switch to something else and pfSense is working ok for us ATM.

I watched the video and tried it. My first 2m with it wasn't awesome. The source plugins are waaay too hard to find. Once I found them on my PC, scanning the QR codes didn't work, so I had to navigate to the plugin page on my phone and open the link for (ex) YouTube in the app. I didn't notice I had to enable the plugin until I couldn't find any YouTube creators. It should be enabled on install. Why would I ever install it and leave it disabled?

So there's room for polish. That said I think it's a fantastic idea and the model is better for both creators and users. However, I think there's an underestimation of the realities of demand aggregation, platform ownership, and what lengths the current platform owners will go to in order to ensure stuff like this is never allowed to exist (if it gets popular). The Facebook email where Zuckerberg was talking about the risk of living on someone else's platform [1] is a great example.

> We are vulnerable on mobile to Google and Apple because they make major mobile platforms. We would like a stronger strategic position in the next wave of computing. We can achieve this only by building both a major platform as well as key apps.

Seeing the effort Google and Apple are making to make Facebook blind to advertising analytics (aka tracking), and not believing the excuse they give about protecting user privacy, I wonder how long they'll tolerate an app that directly threatens their (aka YouTube aka Google) platform control if they're willing to wield their platforms like a weapon to disenfranchise a traditional competitor as big as Facebook.

I think anyone that wants to build a product that lives alongside platform owners needs to ask "how do I do this so the platforms can't kill me if I get popular?" For example, even something as simple as federated logins or OAuth for channel verification / account recovery leaves you vulnerable to the platform owner. I'd love to build something that uses federated logins and OAuth to enable features, but what happens if Google, etc. decide to revoke my API key? Anything built on top of that is ultimately living at the behest of the platform owners in my opinion.

The second question I'd ask is "how does this impact the platforms owners?". There's no way YouTube is going to tolerate an app that blocks their ads while streaming videos from their platform. I'd get rid of the ad-blocking ASAP because it's the best excuse YouTube has to act against the app. If ads are left in and YouTube still works to damage the experience of the app, there's a case to be made for Google / Youtube abusing their market position to prevent competition. That won't go anywhere in my opinion, but the fewer excuses they have, the better.

The last question I think should be asked is "what kind of users do we want to attract?". Teasing ad-blocking as a feature attracts the kind of user that's also going to be interested in things like sponsor block. Rather than shifting users from YouTube to other back-ends that allow more direct support of creators, it might end up being a userbase of freeloaders that are hated by creators.

For creators, I think it's better if they can gain access to multiple platforms as-is. The ads and sponsor spots on YouTube benefit them, so don't take that away. Why would a creator promote the app if it offers users a simple way to opt-out of monetization the creator might be relying on?

If it were me, I'd try to have zero impact on the monetization strategy of platforms that are offered as official plugins. There's a ton of value in becoming the aggregator of the existing platforms. Trying to kill ads while starting out and building on platforms that rely on them is a mistake.

If it gains traction, I would suggest giving creators the option of linking channels across platforms and letting them rank/order platforms used by viewers with the highest ranked platform being used exclusively. That does a couple things. It's better for creators to be able to drive traffic to a specific back-end and it's easier to build if there's no need to de-duplicate content between platforms.

Until it gains traction I would suggest focusing on features that don't rely on Google or Apple to exist. I was able to use the app without logging in or anything, so I assume that means I was using features that don't require the blessing of Google, etc.. I'd avoid putting anything that requires OAuth, API keys, etc. into the core app. Maybe it's already like that. I didn't look at the source (yet).

Overall, I think it's really awesome to see creators working on stuff like this. I'll buy it once I figure out if there's a better way (for the app owner) than using the Play Store.

1. https://news.ycombinator.com/item?id=33538742

Borgbase is pretty good. I’ve used it for 6 years.

The usage graph on each repo is great. I redid my server this year and was accidentally backing up a stale snapshot every night for one of my repos. It would succeed, but without changes. The flat line for usage tipped me off. I’m not sure I would have noticed otherwise since it was a VM image that I could restore and boot, but it wasn’t super obvious it was full of stale data.

This downtime isn’t ideal, but, if downtime is needed to preserve data integrity, I’ll take it over the risk of trying to maintain availability.

I got an email about it right away and I’ve also been getting warnings (that I configured in the dashboard) for inactivity on a repo that’s affected.

I wonder if the "Connect to Supabase" option surfaces the rate limits shown in the manual SMTP config. Those are pretty useful, but if the defaults are actually 3 emails per hour and 60s between emails, I'd say it's important to show them to the user upfront to avoid confusion.

The sliders on the pricing page are weird. It shows me $200 per month for 300k email or 650k emails. Why have all the 50k increments in between with the same price?

This isn't specific to the one here, but I hate the way these services are priced. I don't want a bucket of use-it-or-lose-it service. That's just opaque way of overcharging while making the customer feel like they're getting good value at the top end IMO.

Charge me a base rate, then per-email, and adjust the discount according to my volume.

> If you exceed your plan limits, you will be notified and given the option to upgrade to a higher plan. If you don’t upgrade and repeatedly exceed your plan, your account may be temporarily deactivated.

Why? I realize it's the way everyone does it, but it's dumb. Why should I come back and beg to use the service more? Let me put up a bond (ex: $2500) that determines my monthly rate limit (ex: 1,000,000) to prevent abuse, then stop bugging me and charge my credit card for my consumption every month.

I also wonder if Supabase has configurable fallback SMTP providers. I'd love to use AWS SES for volume and a managed provider like this one as a fallback.

> There are a lot of other things that you're _not_ paying for which we have to price in - regular security audits, zero-day support, etc.

Yeah. I was hesitant to toss examples of actual costs in there because I knew it wasn't really a fair comparison, but I wanted to try to make my point even though I don't have the ability to calculate the real costs.

If I had to sum it up in a way that translates into a good strategy for building mutually beneficial relationships, I'd say "don't profit off my losses". I want a partner like relationship, but the only thing anyone is currently offering is for me to be a customer. I have to make all the predictions on conversion rates, etc., so I'm taking all the risk while the platform owner (ie: you) makes a (high-margin) profit off every user I have, regardless of whether or not I'm generating revenue from that user.

> for social websites, 1M users might be a low number. For B2B SaaS even 1,000 MAU could be high

I would say it makes sense to bucket users into categories and split the feature set accordingly. I think that's what Firebase does [1A]. I think basic login types (magic links, password, social) are free and you only pay for users that need their identity platform.

However, there are a few problems with Firebase IMO. First, I don't like "free". It means my costs aren't realistic and I need to assess the risk of that offering disappearing. IMHO that's just another layer of complexity and risk and I'd rather pay fair value from the start. The second problem with Firebase is that it's going to take a decade of culture change at Google for me to trust any of their products, especially something that's "free".

Back to Supabase, what do you do if you want to add a significant feature that makes the current auth pricing unsustainable? Do you increase the price a tiny bit? What if I have a million free users and don't need that feature for them?

> and we're an order of magnitude cheaper than other Auth providers

This is a little unfair on my part because I don't know the true costs, but if that means you're only charging me 100x the underlying costs vs everyone else charging 1000x, that doesn't make it good value for me, does it?

I'd rather categorize my users and pay accordingly. I know this may not be realistic in terms of creating too many SKUs, but just to make the point (from my perspective)...

1. Free users get magic links. Pricing should be tied to real costs and be commodity like. Minimal cost (to me) is important. Long term, stable, predictable pricing is important. This comes out of my pocket, so I don't want you having a large margin on it and I don't want it fluctuating because small changes can have a large impact on me if I have a lot of free users.

2. Convertible users get passwords, social logins, TOTP, security keys, etc.. Basically they get anything that doesn't have external costs (to you). I'd be willing to subsidize these a bit, but not anything crazy.

3. Paying users get SMS, etc.. Basically they get things that have external costs (to you). I'd pay a large premium for these users and I'd be willing to take on all the external costs in addition to that premium (ex: I pay for all SMS costs).

4. B2B users get any B2B features and my (inexperienced) opinion is they fall into a category where the cost (to me) doesn't matter much.

The other thing that I don't like about having a uniform cost per user is that I know the cost per user isn't uniform and, if my costs aren't a function of your costs, that means you're taking on some risk in the prices you've set. What if your overall prices are too low even though my specific usage is already profitable? Do I have to endure a price increase?

Again, this is uninformed because I don't have a decent knowledge of the true costs, but for my use case (magic links only, bring your own email) the prices feel 100x too expensive, but for a B2B use case they feel 100x too cheap.

I'm sure it's difficult to accommodate all use cases in a way that makes everyone happy, so hopefully my perspective is useful feedback.

1A. https://github.com/255kb/stack-on-a-budget/blob/master/pages...

I'm not the GP.

Unrelated to DBs, I've been thinking about trying to roll my own system for magic links recently. Even though Supabase has some of the lowest costs for MAUs, they're still too high if you're only using magic links, especially considering the related email rate limits [1]. I don't even know if I'm reading that right. Is it 4 auth related emails per hour by default?

I can run a Cloudflare Worker for $0.0000005 vs $.00325 for a Supabase MAU. Assuming it would normally take 2 Worker runs to generate and auth a magic link, a user that signs up and never comes back would cost me 3250x more if I use Supabase.

Not all users are equal and, for low value users that probably never convert to paid users, I don't need to give them a full blown user account with MFA, etc.. Magic link based auth is adequate for what I need and I don't want to pay between 300,000% (for Supabase) and 15,000,000% (for Auth0) markup above the raw compute costs for someone that signs up and never comes back. For a user that converts to a paying customer, I don't really care about the cost as long as I don't have to eat it for every free user I have.

I know there are other costs, and that the requirements for magic links are more complicated than at first glance, but those costs are relatively fixed in the context of magic links, right? If the only major ongoing cost is for email, where I'm basically expected to bring my own provider, the MAU cost for a user that only uses magic links feels like a bad deal.

This isn't just a Supabase issue either. The entire auth industry is similar. I need the simplest part of the existing solution, but I'm forced to pay, in both cost and complexity, for the complicated, expensive part of the solution that I don't need or want to use. Does that make sense?

1. https://supabase.com/docs/guides/platform/going-into-prod#au...

This is the reason we need domains as handles to become the expectation. I don't want an ephemeral handle that Twitter, etc. own. I want a permanent domain that I own.

And I know domains aren't technically permanent, but they're far less risk than ephemeral handles because you actually have some rights as a registrant.

I haven't used Svelte beyond a couple toy tutorials, but, for me, the infrastructure adapters [1] are the most exciting thing. I love the idea of being able to build using Svelte and auto-magically deploy to something like Cloudflare Pages without completely giving up the potential to deploy somewhere else.

1. https://kit.svelte.dev/docs/adapters

It can be made simple, especially if it’s a DNS record that’s unique to a platform. For example, if you set up an MS365 account and are using Cloudflare for DNS, there’s an OAuth like flow where MS will auto-magically update your DNS.

I doubt it. There are so many TLDs now that everyone can have a reasonably decent domain on a thematic TLD. All of those have premium pricing schemes that are unattractive to domainers for the really good domains.

> Apple is not likely to try and register iphone.apple.com on Namecheap.

Definitely not because that’s not how it works. They already own apple.com and can verify any subdomain they want. Plus, I think some of those domains are so valuable the company creates their own registrar to manage them. Ex: RegistrarSafe is a subsidiary of Facebook. They’re definitely not using a consumer grade registrar like Namecheap.

I think domains are complicated for the average user, but if you sell them as premium, globally unique handles for only $10-20 (ish) per year, that’ll create a lot of demand.

Even if it’s only appealing to business users, domains as identities make a lot of sense because it allows a business to be definitively recognized across the internet. There’s no ambiguity or impersonation.

> I could’ve also generated as many valid government approved drivers licenses as I wanted to for anyone of my choosing.

This is a good example of how identity verification is mostly useless in existing systems like code signing. What value is being added if there’s no guarantee the signer’s identity isn’t fake? We might as well be self-signing at that point and I would argue that signing with a domain based identity (@example.com) is better than identity verification.

For example, I want code signed by @example.com, with the GitHub repo at github.com/@example.com, and the website at example.com. It’s time to get rid of all the ambiguity and (matching) handle chasing we have to endure to (try to) mitigate that ambiguity. Domain verified identities would be a huge step forward for good actors that want to (optionally) consolidate all their web assets and accounts under a single, matching, verified namespace.

It’s really strange, and awesome, to see them launch on a .net domain. I have a decent (8 letter) .com with the .net and others to match. I want to build something on the .net, so I hope this builds some awareness for the TLD.

I would love to hear an explanation of why they chose a .net. I always think of it as an OG TLD that throws back to a time when the internet didn’t suck, but I doubt that’s it. Lol.

It can’t be a cost thing, can it?

> For me the main barrier is that I want to have portable/roaming control over my IDENTITY, even if the content hosting is (for now) entirely through a system administered by someone else. If I control the identity, I can at least keep local copies and rehost/repost content later.

This is why I want domains as identities to succeed. I want to own my handle on every platform, but I don’t want to self host.

> If you want the best of both worlds (although this sounds like what you are already doing), I'd suggest hosting your own server, but then using Amazon SES as the outbound email relay. Amazon's outbound costs are very very cheap, and that's what you need the reputation for anyways.

The only thing I'm actually interested in is sending transactional email. I actually think paying a managed provider for it is the most pragmatic approach, but it seems like the existing providers are all pushing the limits of charging what the market will bear and, based purely on subjective info I've seen online, the margins aren't even close to anything resembling fair value (for me).

If there wasn't so much business and technical complexity related to bringing your own IPs, the $10k ish (?) it costs to buy a /24 starts to look like a reasonable expense when put alongside the pricing of a lot of email sending services.