I should be able to associate Personal Properties with a non-Member

Summary: This is the trickier corollary of I should be able to manage properties on the Persons in my Space -- some of my Personal Properties should work even if we don't have a logged-in User.

In airy theory, the idea here is that, if there is no logged-in User, the Personal Properties are stored and drawn from the browser session cookies instead.

Why? Many of the use cases Eric has in mind have to do with the look and feel of the Space within the session: allowing the reader to set some basic preferences. Many of these apply just as much to members of the public as to logged-in Members.

If I am a Member, my Personal Properties should be stored, so they persist across sessions and different machines. But if I'm not, we should make a best-effort to provide the capabilities.

Should this apply to all Personal Properties automatically? Probably not -- in principle, not all of those Properties are necessarily public, even to the Person referred to. So we don't necessarily want to store them in browser cookies, where the user can see them. This probably implies a checkbox meta-Property, saying whether this Personal Property applies to non-Members. (But sanity-check this: it may actually be much easier if it always applies, and it may be an acceptable limitation.)

Making this work consistently is likely to be challenging, and isn't necessarily even possible until we have websockets and client push. It would be easy enough to implement right in the client for Properties that the user edits directly in the client, but making it work for Properties whose values are computed server-side is difficult in the current architecture.