I use Guix

oh yes, guix+hurd is only x86

Yes!

https://guix.gnu.org/manual/1.5.0/en/html_node/GNU-Distribution.html

I love ipv6 but I don’t see how it is related to anything here

Yes your description is just right and is the heart of my question. To use your terminology:

Currently:

• Away from home: Phone -> VM -> Home Server
• At home: Phone -> VM -> Home Server (inefficient!)

Ideally:

• Away from home: Phone -> VM -> Home Server
• At home: Phone -> Home Server

In the ideal case, I would never have to change anything about the wireguard config/status on the Phone, nor would I have to change the domain name used to reach the resource on the Home Server.

Oh hm I didn’t think about your last point, maybe it’s not really an issue at all. I think I’m not 100% on how the wireguard networking works.

Suppose I tunnel all of my traffic through wireguard on the remote server. Say that while I am home, I request foo.local, which on the remote server DNS maps to a wireguard address corresponding to my home machine. The remote will return to me the wireguard address corresponding to the home machine, and then I will try and go to that wireguard address. Will the home router recognize that that wireguard address is local and not send it out to the remote server?

Yes that would work, but it feels a bit cumbersome to have 2 fqdns per service, which I would have to switch between using depending on on whether I’m local or not.

Right but I want to be connected to wireguard always, I just want the DNS/routing to be different based on home vs foreign network.

And so when away do you just directly connect to the external IP and do port forwarding?

So you have a public DNS record pointing to your home IP?

I think tailscale would work, though I’d ideally want to use something like headscale instead, but that’s a bit of a logistical hastle for my setup. Do you know if pangolin can handle this as well?

Try Orgzly with Emacs Orgmode

Emacs Orgmode

emacs org-mode publish

https://orgmode.org/worg/org-tutorials/org-publish-html-tutorial.html

emacs org-mode meets all of these criteria

codeberg

it’s like github but non-corporate free software

it’s very polished and featurful

it’s built upon/by the same devs as forgejo, which is open tech to self host your own git server (with federation potentially coming), so supporting one supports the other

Thanks!

Do you happen to know what certs would be most “applicable” in this case? Something like OSWE?

Any advice on requirements to have a shot at appsec jobs?

I have my sec+ and my job is devops. We do everything in AWS (no on prem at all). However I have no actual cyber experience. Our team is pretty small, so I do as much dev as anyone else and as much ops as anyone else (deploying/managing cloud infrastructure), including standard security stuff like IAM and network configuration. It’s also a small unknown company.

Is this enough to try and directly break into appsec, or do I need to start with another “cyber” role like SOC analyst or security engineer or something like that? I also plan on getting my OSCP at some point soon if that’s relevant.

Have you heard something recent? I feel Signal has been saying that for years now.

I don’t care about XMPP as a protocol versus some other messaging protocol much, but I care a fair bit about the wdespread adoption of federated XMPP

I don’t quite understand what this means, could you elaborate?

if this service using this protocol becomes very popular, will the service seek to eliminate the open role of the protocol

That is a valid concern, though the point of the article is to try and convince people why it won’t happen like it did with Google or might with Meta for structural reasons (rather than “oh but we’re different” reasons).

The main difference I see with Snikket vs Google Talk is that Snikket is not only libre client software, but libre server software as well. The point of Snikket is that individual people host it themselves, not that the Snikket devs run a bunch of Snikket servers which require their Snikket client for connection and just so happen to use xmpp to power it. Really all Snikket is (right now) is a prosody server with some pre-configurations and easy install, as well as an android/ios app which are general xmpp clients that are designed to work well when connected with Snikket servers.

Now it could still go south in a similar way to Google Talk, in that maybe a bunch of people start running Snikket servers and using Snikket clients, and then the Snikket devs start wall gardening the implementation. That would be bad, but the users (both server runners and client users) would be in a much stronger position to pivot away from those decisions.

I think it’s at least an interesting idea (hence why I posted it) for the reasons the author mentions: striking a balance between trustless freedom and interface stability/agility.