New #taproot #design principle: build software which feels safe — discomfort, awkwardness, security and privacy are all secondary to safety of data.

#taproot / #webactions design #principle: easy things should be easy, remove friction so hard things are no harder than they need to be.

I’m noticing a #taproot pattern emerge whilst writing the simplified auth code: multiple event listeners which don’t know about each other working on the same object, augmenting and changing it.

E.G. RememberMeListener looks for an encrypted cookie with a URL (my user ID of choice) in — if it finds one it makes an ActivityStream person object and puts it in request.attributes.user.

Then, in the same event chain but at a lower priority level, the Contacts module looks in request.attributes.user for a URL. It looks up the URL in my people DB and, if there is anyone, augments request.attributes.user with all the extra info (full name, roles, photo URL, rel value, etc.)

Then, another listener could run, looking for request.attributes.user with only URL — and look the URL up on identengine.com, caching the response.

Other example is @-name autolinking, working on a similar basis of: basic transformation (raw data => common data format), then progressive augmentation adding URLs, names and rel values.

I think this a very powerful and flexible pattern and something I will make a founding principle of Taproot.

.Brennan Novak yeah, it’s like driving — the ability to concentrate on your overall journey, the road in the distance, the road ahead, the road directly in front of you, the road behind and all the various controls at the same time.