• 10 Posts
  • 313 Comments
Joined 2 years ago
cake
Cake day: March 19th, 2024

help-circle




  • I suppose that begs the question of whether or not privacy (as used by this community) inherently means private in the colloquial sense, like the way a diary is private. Because to me, a e.g. public static website with no kind of profiling of its users is privacy-respecting, but obviously not private in the colloquial sense—it’s a public resource.

    I do use SMS sometimes and I use it strictly for things that I’m happy to be basically public. Same for using other protocols like unencrypted email.

    A stock smartphone is also locked in to mandatory telemetry, like a stock dumbphone. The practical difference is that there’s a much smaller community for installing custom FOSS OSes onto dumbphones compared to smartphones.


  • communism@lemmy.mltoPrivacy@lemmy.ml'Dumbphones' Are Not Private
    link
    fedilink
    arrow-up
    31
    arrow-down
    1
    ·
    22 days ago

    I think you’re conflating security with privacy. Not that they are unrelated, but something can be e.g. unencrypted but lack telemetry.

    Not that dumbphones are inherently private, but I don’t think they’re less private either. They’re just what you use if you have no need for all the smartphone functions.










  • I think once Forgejo gets ActivityPub integration working it will really help for migration. I know federated platforms like Mastodon struggled with adoption because I think a lot of folks struggled to wrap their heads around the fact that there’s no “default instance” and they have to choose their own instance, but hopefully for a programming crowd that won’t be an issue. It would massively help with the “well I could move to a different website but there’s no obvious second choice I can move to” issue; you can just head to any Forgejo instance and interact with any other federated instance.




  • You get a domain name, and use an A record to point it towards your server’s public IP address.

    You tell nginx to forward requests to a given domain. For instance, you could tell nginx to forward requests to foo.bar.com to 127.0.0.1:1337. To do this:

    http {
        server {
            server_name foo.bar.com;
            listen 80;
            
            location / {
                proxy_pass http://127.0.0.1:1337$request_uri;
            }
        }
    }
    

    Note that this is a very basic setup that doesn’t have HTTPS or anything. If you want an SSL certificate, look into Let’s Encrypt and Certbot.

    Also, the service you’re hosting (which I’m not familiar with) may have an example reverse proxy config you should use as a starting point if it exists.



  • Been self hosting email for a good while now and it’s been largely painless. My emails are not getting marked spam either. Although my only outgoing mails are to FOSS mailing lists and occasionally to individuals, not for anything business related.

    I would say that if self hosting email sounds like something you’d be interested in, then it probably is worthwhile for you. I like being able to configure my mail server exactly the way I want it, and I have some server side scripts I wrote for server side mail processing, which is useful as I have several different mail clients so it makes sense to do processing on the server rather than trying to configure it on my many clients. It definitely falls into the “poweruser” category of activities but I’ve had fun and I enjoy my digital sovereignty.