Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)TE
Posts
0
Comments
34
Joined
2 yr. ago

  • The simple answer is yes.
    It's possible to encode or tunnel anything over any protocol.

    The next question is why isn't it done more?

    1. http has basically become the defacto internet protocol for all media content. This has resulted in a lot of other protocols from becoming blocked due lack of support or due to firewall rules.
    2. efficiency. http (and all the other protocols it runs atop) have become highly optimized for doing what it does. To layer something like http over another protocol, would certainly be possible but it would likely be slower, less responsive and lack a lot of the niceties that make http work as well as it does.

    For the above reasons it's actually more common to see other protocols run on top of http. This is especially common to prevent blocking and censorship by making the traffic look like normal http traffic when it may actually be private messaging apps, file transfers, VPN, etc.

  • If you want to be able to trim off the ends, I suggest a double fisherman's instead (aka the double overhand stopper) with both strands (hold them together while you tie and treat them as a single strand).

    https://www.animatedknots.com/double-overhand-stopper-knot

    With either knot, after you trim, you can melt the ends of the elastic cord. It will "mushroom" a bit, which will also prevent the tips from creeping into the knot and coming loose.

  • A flat overhand bend in the elastic cord is what I recommend: https://www.animatedknots.com/flat-overhand-bend-knot

    Justification:
    Simple, not bulky, reasonably secure against shaking loose, and relatively easy to untie.

    As suggested in another comment, a double figure eight could be used as well. It will be more bulky and a bit less likely to come loose.

  • The addAddress call may just be configuring the local side of the VPN. It's hard to know without looking at the rest of the code.
    The general workflow when establishing a VPN connection is:

    • open a socket to the destination VPN service (ProtonVPN, or whatever suspect service).
    • configure parameters such as DNS, split tunneling, and which networks to route over the VPN (generally everything from your local system, except the VPN connection itself).
    • update the local routing so traffic starts flowing over the VPN.

    addAddress may just be part of the configuration. A very cursory search suggests that OpenVPN may be being used as the underlying VPN implementation framework (not uncommon).