Change how hostname/devices work

[ErikBjare]

A few things we should consider changing:

• [x] Every device/installation should have a unique ID (a UUID) that does not change if the hostname is changed.
  • Completed in https://github.com/ActivityWatch/aw-server/pull/61 and https://github.com/ActivityWatch/aw-server-rust/pull/69
• [ ] If a bucket is created with a special hostname/UUID "local" or similar then it should default to the hostname/UUID of the running instance.
  • Or it should be the responsibility of the watcher to retrieve the UUID from /api/0/info and use it during bucket creation. Although defaulting to the local value seems like better API ergonomics (and would maybe make migration easier).
  • As an example, it is required for the web watcher to work properly with sync (see https://github.com/ActivityWatch/activitywatch/issues/307)
• [ ] Additionally, we might want to move the hostname (later UUID) bucket attribute into the data field of buckets. This would impose specific semantics on the data field of buckets (which we currently lack) so might need further discussion (i.e. which data attributes are reserved for internal use in aw-server?)

Originally discussed here: https://github.com/ActivityWatch/aw-server-rust/issues/61#issuecomment-531687577

[johan-bjareholt]

Another thing, we might want to make buckets user-specific on platforms which have multi-user support. See this forum post https://forum.activitywatch.net/t/add-windows-username-to-bucket/374/2

[nilsbentlage]

One problem i have (and maybe its related to this):

I have two buckets, on is [name-of-my-macbook].local and the other [name-of-my-macbook].fritz.box

I guess the issue is the following: when i start my macbook with lan-connection plugged in, i get another host name (and also another Bucket, if i understand that right) as i get when im connected via wifi. Am i able to avoid that?

Thx so much. You made a great tool!

[BelKed]

I also had this problem and this helped me: https://github.com/ActivityWatch/activitywatch/issues/554#issuecomment-1114200180