• 0 Posts
  • 11 Comments
Joined 2 years ago
cake
Cake day: June 3rd, 2023

help-circle
  • Rowan Thorpe@lemmy.mltoSelfhosted@lemmy.worldEmail hosting over NNCP
    link
    fedilink
    English
    arrow-up
    7
    ·
    edit-2
    3 hours ago

    I hadn’t even heard of the underlying protocol NNCP yet, and it seems to solve out of the box several things I was trying to do in some of my own hobby-projects. I’d been battling with automating and integrating Tor/I2P, Openssl, Tox, GPG, Wireguard, etc. If NNCP lives up to the hype it will be a big shortcut, when I next get time to work on stuff :-)






  • In terms of the “default instance” suggestion, I have an interesting hybrid suggestion. What about having an “easy on-ramp” instance where you get registered for one month with a hard-exit (auto-migrate to other instance, perhaps using some kind of federated-auth/token system for the migration, and forced password-setup on first use of the new instance). At any point during on-ramp the user could configure destination-instance from a list in the settings (or configure auto-export for manual import to any other “auto-migrate-unsupported” instance), with optional early-migration if the user has decided before the end of the month. Optionally a recommendation engine could iteratively curate a list of suggested instances based on usage during on-ramp (admins of those instances could provide - limited number of - tags of their choosing for the engine to use for matching). That part could be opt-in because probably a lot of users would find it creepy. The UX would need to be very user-friendly “pointy clicky” because that would be the overwhelming target demographic of such an instance. I think “on-boarding and educating” is better than “gatekeeping” (which feels like the “if you need to ask the price you can’t afford it” shopping trope). A nice side-effect is it already painlessly introduces users to the killer-feature “easy migration” between instances due to data-portability.



  • I remember having a bit of fun playing things like Stunt Car Racer on MS-DOS back in the early 90s for a few days. Yeah, that’s about it. That’s the best I can do even when I’m trying to be charitable. As soon as I owned my first computer (late 90s) I bought a Linux magazine, installed a distro from a cover CD-ROM, and never looked back.



  • Rowan Thorpe@lemmy.mltoLinux@lemmy.mlVPS encryption
    link
    fedilink
    arrow-up
    0
    ·
    edit-2
    7 months ago

    If you’re only talking about Storage (data at rest) or Network (data in transit) then encrypt/decrypt offsite and never let symmetric keys (or asymmetric private keys) near the VPS, or for in-transit you could similarly setup encrypted tunnels (symmetric/private keys offsite only) where neither end of the tunnel terminates at the VPS. If you’re talking about Compute then whatever does the processing inherently needs access to decrypted data (in RAM, cache, etc) to do anything meaningful. Although there are lots of methods for delegating, compartmentalising, obfuscating, etc (like enclaves, TPM/vTPM…) the unavoidable truth is that you must trust whomever owns the base-infra ultimately processing your data. The one vaguely useful way to use “other people’s computers” trustlessly is with SMPC (secure multi-party computation) spread sufficiently widely across multiple independent (preferably competing - or even adversarial!) virtual-computation providers, with an “N-of-M keys” policy that avoids any single provider being able to attain a meaningful level of access to your data independently, or being able to view tangible portions of your data while providing functionality during SMPC. That stuff gets super-niche though.