Note by @fastfinge

Edit: All of the below has been fixed. Docs are updated, the bug with the conf file is fixed. And see the reply in this thread for how to share a clipman server. Plus it was clarified in the manual. Gotta love quick updates! Clipman by @FreakyFwoof is one of those things I’d had on my list to set up ever since the IOS app came out. I finally did it. Should have done ages ago. The only weirdness involves running servers in docker behind reverse proxies. If you do that, a few things to know: first, it writes files you will need access to later. So don’t use bind mounts. Second, the importable config file it writes is wrong. You have to enter it in to the apps yourself. And the format has to be clip.example.com. If you use clipman:// examples like in the manual, it will try to use plain text and fail. When saving settings on IOS,you have to specify the port, even if it’s the default, because it requires a specified port or the settings won’t save. Lastly, it’s one server, one database. I thought I could add tokens for family members, but no. They need there own clipman server on there own host.

@fastfinge There are people using the public clipman server right now, same token, different history passwords. The database buckets are of course not shared.
If you think of the server token like a key card to get into the building, then the history password like a combination lock on a room within that building. You share the same lock between clients, they can communicate.
If you have two clients that enter two different history passwords, no matter how loud you shout, no other client will hear you.

The manual did mention this but it wasn't clear, so have tried to make it more so.
onjlouis.github.io/Clipman/server/manual.html#sharing-a-server

@FreakyFwoof So one small issue with this design. Doesn't it mean if I make a typo on one of my machines, and enter an incorrect password, it suddenly won't share history with all the others, and I won't know why? I might suggest a message when first setting up a machine alerting if it's creating a new database bucket instead of joining an existing one. It's not an error, of course, but it's good to know that what happened might not have been what I intended. Maybe it already does this; right now I have my dad on a different server instead, so I haven't tried that yet.

@fastfinge Interesting. I'm springboarding here, so...
If you type a thing, let's say 'test1' then it tells you a new bucket is created.
'test' does not, so now you know you joined someone else's bucket, or your own.
Do you think that's a good idea?
I'm genuinely asking, not being patronizing.
It feels to me like one of those 'Your user is incorrect' so you say 'aah, that means my password is not...'
'Your password is incorrect' so you say 'aah, the email is not.'

One of those.
I don't know what's the right thing to do here.

@FreakyFwoof Yeah, I think that's right. The main thing is to know if you're joining an existing bucket, or if a new bucket was created. If a new bucket was created, and you did not expect that to happen, it's on you to figure out why. But now you know what happened, so you don't waste time trying to figure out why machine 1 isn't syncing the clipboard, when it is, just not in the same bucket is machine 2.

@fastfinge interesting. Would have to be client-side for every client, will have to see how that works out, but yeah typos will screw you up lol

@FreakyFwoof Yeah, client-side is probably the only way to do it. Either that or make the server log every time it creates a new bucket. So if someone was troubleshooting, they would see logs like "Sam's Framework joined the server and created a bucket. Sam's mac joined the server and used an existing bucket. Sam's iPhone joined the server and created a new bucket." So at least then, when something wasn't working, someone who checks the server logs would understand that iPhone did join the server, it just created a new bucket for itself.

@fastfinge Logging may do that already, and the folder structure definitely shows if you have a new bucket.

@FreakyFwoof Ah, okay. Of course, I'm running in docker, so I don't have easy access to the folder structure. Maybe a fix would be to make the page at clip.interfree.ca say "running with 3 buckets" or whatever? Then people would know if there are unexpected buckets. But it could be that logging already does this. I'll test in a bit.