Every WiFi router and network has something called an SSID and a BSSID. The SSID is the friendly name that you use to show off your puns to your neighbors. The BSSID is a 6 byte MAC address. All devices use the BSSID when connecting and communicating.

With a non hidden SSID, your router broadcasts the SSID and BSSID.

The BSSID doesn’t change even if you change your SSID (Though APs with support for multiple SSID create a different BSSID per network) and it’s what is actually used for geo location.

When it’s hidden, it doesn’t send the SSID out, but sends out packets with the BSSID. Clients then scream out to the void “anybody know the SSID ‘My Secret SSID??’” Then it’ll respond.

So basically hidden networks still send out the unique identifying address and then when you take your phone with you, you’re just telling everybody what your home WiFi is called.

Hidden SSIDs are not that useful.

https://forum.syncthing.net/t/discontinuing-syncthing-android/23002

According to this post, it was partly that and lack of maintainers. Given there’s maintainers for a fork, I’m curious why they didn’t bring them into the main project.

Reason is a combination of Google making Play publishing something between hard and impossible and no active maintenance. The app saw no significant development for a long time and without Play releases I do no longer see enough benefit and/or have enough motivation to keep up the ongoing maintenance an app requires even without doing much, if any, changes.

We’re sort of in this situation because the official project decided not to continue providing an official Android app, yet people want to use it on Android forcing unofficial versions to be created and maintained.

I get that they don’t want to deal with Google Play anymore, but somebody has to deal with it and them not owning the app is putting users at risk.

How would that work? The use case is for previews for pull requests. Somebody submits a change to the website. This creates a preview domain that reviewers and authors can see their proposed changes in a clean environment.

CloudFlare pages gives this behavior out of the box.

It is for pull requests. A user makes a change to the documentation, they want to be able to see the changes on a web page.

If you don’t have them on the open web, developers and pull request authors can’t see the previews.

The issue they had was being marked as phishing, not the SSL certificate warning page.

Rebase still means you have to resolve conflicts, but it can be worse because you may have to resolve conflicts across multiple commits that you’re rebasing on top of a conflict.

A newer release, v0.6.30 is already released to fix an issue with OneDrive integration.

Looks like they finally finally made their slim image tag smaller than the main image:

ghcr.io/open-webui/open-webui:v0.6.30-slim    7c61b17433e8   46 hours ago    4.3GB
ghcr.io/open-webui/open-webui:v0.6.30         c1ac444c0471   46 hours ago    4.82GB

Though only saving .5GB of space is not very slim. I use OpenWebUI in my home lab, but this issue just made me question the quality of the project a tiny bit.

I’ve been running my own mail for 10+ years. I recommend rspamd for spam filtering. It took the place of SpamAssasin, grey listing, SPF checking, etc. All in one single system.

Depends on the watermark method used. Some people talk about watermarking by subtly adjusting the words used. Like if there’s 5 synonyms and you pick the 1st synonym, next word you pick the 3rd synonym. To check the watermark you have to access to the model and probabilities to see if it matches that. The tricky part about this is that the model can change and so can the probabilities and other things I don’t fully understand.

How do you expect the packets to actually route? If you run Tailscale and your VPN on your phone, they might fight with each other for control of the routing table.

If you’re trying to use Tailscale exit note to then route through Tailscale to one node running gluetun to Mullvad. That’s going to be complex because against they both want to mess with the routing table.

Tailscale natively supports Mullvad: https://tailscale.com/mullvad

Okay it was a little hard to read since your post was missing formatting. TS_SUBNETS is what controls what CIDRs are announced through Tailscale. Since you’re not using Docker networking for Jellyfin, it would be whatever subnet the host is on. Maybe it’s 192.168.x.y

Gluetun doesn’t make any sense here. You’re forcing all the traffic for from Jellyfin to go through Mullvad, but you need to be able to connect to Jellyfin because Jellyfin is a service you connect to.

Since your Tailscale is host network mounted, you’ll be able to expose your Docker network subnets over Tailscale then access Jellyfin. This is done via the TS_SUBNETS env variable. Docker will use a 172.16.0.0/12 subnet.

You probably intend to gluetun your downloading software, not Jellyfin.

Was that anything more than just rumors? Letting a currently monopolistic company keep the browser because another bad billionaire might buy it and do something bad with it just prevents anything from changing.

Your options are to run smaller models or wait. llama3.2:3b fits on my 1080 Ti VRAM and is sufficiently fast. Bigger models will get split between VRAM and RAM and run slower but it’ll work.

Not all models are Gen AI style LLMs. I run GPU based speech to text models on my GPU too for my smart home.

Who organized this form? Is there something official to make it look like it’s not just signing me up for spam?

I use a variant of this: https://github.com/linuxserver/docker-wireguard

You don’t need two different containers for this. They’re going to either fight each other for control over the networking tables or run wireguard in wireguard

So I had a chance to try this out. It wasn’t on Google Play Store, only F-Droid. There isn’t really SSO support, you either login with User/Password or a token. Instead, I login with my browser, get the token and paste it in. That works fine, but an ideal world is just pop up an browser WebView and go through the flow, then grab the token. Maybe it was intentional, but PaperlessShare registered as an Open handler for PDFs and the share menu, whereas this is only share menu. This seems to mean that I need to grant file access, whereas the open handler didn’t need that I think.

Overall, it does the job and gets my docs uploaded.

My prediction is that manually reviewing user creation won’t scale to a high level and unless systems develop spam detection and reputation management similar to email then it’s not going to be limited to just one or two bad instances.

Its trivial to create my own instance with a new domain and there’s no limitations against sending ActivityPub messages to a server. Unfortunately the simplest fix is for big instances to restrict what instances can communicate to it, but that causes centralization.

Plus, we don’t need to be huge. There’s no benefit from it.

The benefit is breadth and depth of communities. Reddit is great because if you are interested in a topic, there’s a bunch of people talking about it.

How hard would it be to contribute these improvements back to the project in the form of either distro package updates or documentation changes? Did you consider that?

Can you expand on the OIDC/OpenID support? Does it support SSO based authentication to Paperless? That’s my biggest problem with PaperlessShare right now. I can’t actually sign in because I use an SSO provider.