• 1 Post
  • 46 Comments
Joined 11 days ago
cake
Cake day: November 10th, 2025

help-circle
  • zheres your standard two tap mixer faucet: mixer faucet

    At both taps full open you have full flow/pressure from both the hot water and cold water supply only restricted by the valve full open orifice.

    Now add an additional valve to the mixed outlet of the faucet with both hot and cold feeding into the line that runs into it. If the valve is sized to accommodate the full flow from both valves feeding into it, the full combined pressure/flow from both cold mains and hot supply is available.

    Also, once you set the temperature you like by turning the temp taps, that temp will be available to you at any flow rate on demand. Nothing you do to the mixed valve will change the temperature of the flow. This is especially useful if your hot temperature is very hot, you can have nice warm water to wash your hands every time without worrying you might scald yourself.










  • “you could block logged out users but that would impact many lurkers”

    “regardless you might not be logged in at all, you should still be allowed to browse content”

    Fundamentally, what I’m suggesting is a fork in the road. Either an instance admin can set up to eliminate scrapers by making the instance private to only registered users,

    or they can maintain their instance as public and deal with more arcane methods to attempt to eliminate scraping.

    The issue is that if the infrastructure isn’t in place for the instance operator to decide to make their service private, then everyone is opted in to the Scrapers vs Countermeasures war with no alternative.

    Privacy and encryption just work, it seems like not building the infrastructure to enable the network to function with them in place is a mistake.

    To me, and to many users, what we want is fast load times, quick federation, and reliable service, all things that benefit from reducing traffic load to only registered users.


  • Fediseer seems like a good solution, essentially a whitelist vouch system with touching at second hand.

    Regarding the media hosting, again it seems like something that could rely on a method of identifying the user request directly with their user account before responding to the request. Cookies could be an option for this, though they are falling out of favor. Alternately, and more securely, it could be a cryptographic handshake where the user’s home instance and the instance hosting the post generate a public key using their two private keys for the user, and the user provides the public key when making pull requests from the federated instance. The keys could be batch generated when an instance first federates content with another and then assigned to user accounts the first time the user makes a pull request through a link from their home instance to the federated instance.

    Secure Scuttlebutt Protocol already deved the encryption methodology that could be cross applied for a lot of this: https://ssbc.github.io/scuttlebutt-protocol-guide/ though I am of course not suggesting SSP be adopted whole cloth, and there are a bunch of other OS projects with encryption that could be used. This is just the one that comes to mind.

    (edit: also I am in favor of finding methodologies that work whether CloudFlare is used by the instance or not, obviously CloudFlare has advantages but as we have seen also is a vulnerability of the network.)



  • The thing that confuses me is, wouldn’t a whitelist for federated instances and request frequency throttling at the account level solve this issue?

    I suppose this would require that the client not have a public front end that keeps full navigation functionality, but for a smaller instance that seems like an easy sacrifice to make in exchange for stability.

    “But then how will new instances get federated?” maybe they have to actually talk to the admins of other instances to get vouched in to the whitelist. Just because the network is distributed doesnt mean it needs to be fully inclusive by default, and in fact it explicitly isn’t.

    I’m assuming I’m missing something super basic that makes all this not enough, bots spoofing the requests with the credentials of a whitelisted instance maybe?

    Seems like maybe the instances should have encrypted keys that handshake each other with batch requests.

    Am I on to something or just wildly gesticulating?





  • Yes, closing your sinuses is a natural reflex response for humans, and people have greater or lesser at will control over it.

    The nose holding for swimming is more about how strong that sinus closure is and endurance. People with larger sinus openings have a more difficult time keeping them closed and resisting pressure like water entering from jumping into a pool. Also some people have a hard time keeping them closed for any prolonged period.

    In other words, you just have totally ripped sinuses breh.


  • Could this be the run-up to Apple acquiring Perplexity? I remain convinced that Apple defending their internal AI division shows they are close to a major acquisition and are just waiting for a valuation dip on one of the major competitors. Distribution is a solved problem for Apple, what they need is proven usecases and a competitive tech stack.

    That said, search and consolidating multiple model APIs isn’t a great match for what Apple needs, and their optics aren’t great. My bet is still on Apple acquires Anthropic in 2026.


  • As a non-coder interested in self hosting and somewhat aware of cybersecurity, this is the most relevant take for me.

    An application that facilitates safe self-hosting of many different service is great, however for it to be actually safe and useful it must either be a cybersecurity service keeping up with the pace of threats (which is essentially the corporate closed source model) or from the ground up be an educational platform as much as an application. Documentation needs to not only be comprehensive, but also self-explanitory to a non-technical audience. It is not enough to state that a setting or feature exists, it must also be made clear why it should be used and what the consequences of different configurations are.

    This approach is almost never done effectively by FOSS projects unfortunately. Fortunately I think we are at the point where it is completely feasible for this type of educational approach to be fully replicable and adaptable from a creative commons source to the specific content structure of the application user manual using LLMs (local ones). The big question is, what is the trusted commons source of this information? I suppose there are MIT and other top university courses published for open use online that could serve as the source material, but it seems like there is likely a better formatted “IT User Guide Wiki” and “Cybersecurity Risk and Exploit Alert List” with frequent updates out there that I’m not aware of, perhaps the annals of various cybersecurity and IT associations?

    Anyway I’m aware this is basically calling for another big FOSS project to build a modular documentation generator, but man would it help a lot of these projects be viable for a wider audience and build a more literate public.