# I am the Watcher. I am your guide through this vast new twtiverse.
# 
# Usage:
#     https://watcher.sour.is/api/plain/users              View list of users and latest twt date.
#     https://watcher.sour.is/api/plain/twt                View all twts.
#     https://watcher.sour.is/api/plain/mentions?uri=:uri  View all mentions for uri.
#     https://watcher.sour.is/api/plain/conv/:hash         View all twts for a conversation subject.
# 
# Options:
#     uri     Filter to show a specific users twts.
#     offset  Start index for quey.
#     limit   Count of items to return (going back in time).
# 
# twt range = 1 26
# self = https://watcher.sour.is/conv/qusduaq
Hmm when I said "Wireguard is kind of cool" in this twt now I'm not so sure 😢 I can't get "stable tunnels" to freak'n stay up, survive reboots, survive random disconnections, etc. This is nuts 🤦‍♂️
Hmm when I said "Wireguard is kind of cool" in this twt now I'm not so sure 😢 I can't get "stable tunnels" to freak'n stay up, survive reboots, survive random disconnections, etc. This is nuts 🤦‍♂️
Hmm when I said "Wireguard is kind of cool" in this twt now I'm not so sure 😢 I can't get "stable tunnels" to freak'n stay up, survive reboots, survive random disconnections, etc. This is nuts 🤦‍♂️
Hmmm really not getting this at al 🤦‍♂️ So far things appear to be a bit more stable, but the only changes I made was to assign addresses to peers of the form 172.30.0.X/32 instead of 172.30.0.X/24 and setting AllowedIPs to 0.0.0.0/0 for mobile peers (phones, etc) and X.X.X.X/24, Y.Y.Y.Y/24 for more static peers (remote VMs) where X and Y are the LAN and Wireguard subnets.
Hmmm really not getting this at al 🤦‍♂️ So far things appear to be a bit more stable, but the only changes I made was to assign addresses to peers of the form 172.30.0.X/32 instead of 172.30.0.X/24 and setting AllowedIPs to 0.0.0.0/0 for mobile peers (phones, etc) and X.X.X.X/24, Y.Y.Y.Y/24 for more static peers (remote VMs) where X and Y are the LAN and Wireguard subnets.
Hmmm really not getting this at al 🤦‍♂️ So far things appear to be a bit more stable, but the only changes I made was to assign addresses to peers of the form 172.30.0.X/32 instead of 172.30.0.X/24 and setting AllowedIPs to 0.0.0.0/0 for mobile peers (phones, etc) and X.X.X.X/24, Y.Y.Y.Y/24 for more static peers (remote VMs) where X and Y are the LAN and Wireguard subnets.
@prologic Hm, I’m afraid I can’t be of much help here. Wireguard always “just worked”, I didn’t have the need yet to dig deep into troubleshooting. 🤔
@prologic Hm, I’m afraid I can’t be of much help here. Wireguard always “just worked”, I didn’t have the need yet to dig deep into troubleshooting. 🤔
@prologic Hm, I’m afraid I can’t be of much help here. Wireguard always “just worked”, I didn’t have the need yet to dig deep into troubleshooting. 🤔
@movq What's your setup like? How many peers? How are they configured? (if you can share)
@movq What's your setup like? How many peers? How are they configured? (if you can share)
@movq What's your setup like? How many peers? How are they configured? (if you can share)
I _think_ this is what I was missing in my understanding:

> In other words, when sending packets, the list of allowed IPs behaves as a sort of routing table, and when > receiving packets, the list of allowed IPs behaves as a sort of access control list.
>
> This is what we call a Cryptokey Routing Table: the simple association of public keys and allowed IPs.
I _think_ this is what I was missing in my understanding:

> In other words, when sending packets, the list of allowed IPs behaves as a sort of routing table, and when > receiving packets, the list of allowed IPs behaves as a sort of access control list.
>
> This is what we call a Cryptokey Routing Table: the simple association of public keys and allowed IPs.
I _think_ this is what I was missing in my understanding:

> In other words, when sending packets, the list of allowed IPs behaves as a sort of routing table, and when > receiving packets, the list of allowed IPs behaves as a sort of access control list.
>
> This is what we call a Cryptokey Routing Table: the simple association of public keys and allowed IPs.
@prologic Nothing special, really. 🤔 We have “site-to-site” (a pair of servers) and “point-to-site” (one server, many clients) setups, pretty much the same as described here:

https://wiki.archlinux.org/title/WireGuard#Usage

Which operating system(s) are you using?
@prologic Nothing special, really. 🤔 We have “site-to-site” (a pair of servers) and “point-to-site” (one server, many clients) setups, pretty much the same as described here:

https://wiki.archlinux.org/title/WireGuard#Usage

Which operating system(s) are you using?
@prologic Nothing special, really. 🤔 We have “site-to-site” (a pair of servers) and “point-to-site” (one server, many clients) setups, pretty much the same as described here:

https://wiki.archlinux.org/title/WireGuard#Usage

Which operating system(s) are you using?
@movq I _think_ I misunderstood some aspects of Wireguard as mentioned here, not 100% sure, but so far things are much happier now with assigning /32(s) as Tunnel IP(s) for Peers and being a bit more thoughtful about the AllowedIPs 🤞 I'm only playing around with 3 devices right now, my core router (RouterOS), an Ubuntu 22.04 VM over at Vultr and my iPhone.
@movq I _think_ I misunderstood some aspects of Wireguard as mentioned here, not 100% sure, but so far things are much happier now with assigning /32(s) as Tunnel IP(s) for Peers and being a bit more thoughtful about the AllowedIPs 🤞 I'm only playing around with 3 devices right now, my core router (RouterOS), an Ubuntu 22.04 VM over at Vultr and my iPhone.
@movq I _think_ I misunderstood some aspects of Wireguard as mentioned here, not 100% sure, but so far things are much happier now with assigning /32(s) as Tunnel IP(s) for Peers and being a bit more thoughtful about the AllowedIPs 🤞 I'm only playing around with 3 devices right now, my core router (RouterOS), an Ubuntu 22.04 VM over at Vultr and my iPhone.
@prologic I find the L2 mode where you have one interface and multiple hosts to be tricky. Its best if you are trying to make a full mesh style. But then all hosts need to be able to see one another.

I have had more success using point-to-point connections where there are only two ends to each interface. It means you have a ton of interfaces and udp ports. but you can share the host IP across the interfaces. Add to that a simple router proto ala OSPF or RIP and you can navigate around not having a full meshnet.

I have dozens of localnet wireguard connections and many more connections to others that use bgp for route propagation.
@prologic I find the L2 mode where you have one interface and multiple hosts to be tricky. Its best if you are trying to make a full mesh style. But then all hosts need to be able to see one another.

I have had more success using point-to-point connections where there are only two ends to each interface. It means you have a ton of interfaces and udp ports. but you can share the host IP across the interfaces. Add to that a simple router proto ala OSPF or RIP and you can navigate around not having a full meshnet.

I have dozens of localnet wireguard connections and many more connections to others that use bgp for route propagation.
@xuu Yeah I'm basically doing point-to-point or multipoint-to-point which sso far is working well 👌
@xuu Yeah I'm basically doing point-to-point or multipoint-to-point which sso far is working well 👌
@xuu Yeah I'm basically doing point-to-point or multipoint-to-point which sso far is working well 👌