[sudo-discuss] SUDOregistry?

Tue Feb 18 23:53:38 PST 2014

I wouldn't mind contributing to this/sharing some info about myself as it's
reasonably easy to update (honest, I really am not that web savvy).
Otherwise, it will happen when it happens.

-chrisbee

On Tue, Feb 18, 2014 at 5:42 PM, Jenny Ryan <tunabananas at gmail.com> wrote:

> Perusing userpages on break at work, and Romy's is extra-inspiring!
> https://sudoroom.org/wiki/User:Romyilano
>
> Jenny
> http://jennyryan.net
> http://thepyre.org
> http://thevirtualcampfire.org
> http://technomadic.tumblr.com
>
> `~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`
>  "Technology is the campfire around which we tell our stories."
> -Laurie Anderson
>
> "Storytelling reveals meaning without committing the error of defining it."
>  -Hannah Arendt
>
> "To define is to kill. To suggest is to create."
> -Stéphane Mallarmé
> ~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`
>
>
> On Tue, Feb 18, 2014 at 2:49 PM, eddan.com <eddan at sudoroom.tv> wrote:
>
>> I just wanted to chime in to thank everyone working on this, especially
>> Jenny, for being so thoughtful and careful about these trade-offs between
>> varying degrees of transparency and collaborative effectiveness. Sudo Room
>> has been most exceptional in this regard throughout, even when it's been
>> hard and when there've been no examples to follow.
>>
>> I also wanted to add that I think there are also circumstances in which
>> having a subset of people (from multi-stakeholder points of view, etc), be
>> the trusted gatekeepers of these borderline cases of information sharing is
>> the wisest course to maximize benefits for all. So long as the gatekeepers
>> aren't and don't become choke-points without enough capacity to
>> double-check and distribute oversight to affirm people's trust in the
>> process.
>>
>>
>> In an earlier email, I had expressed concern that this would be funneled
>> through only one person. Someone pointed out to me that its brevity made it
>> come off as rude, and I apologize for that.
>>
>> On Feb 18, 2014, at 2:39 PM, David Keenan wrote:
>>
>> And I should add, Mycelia does seem like the most useful way to aggregate
>> info re: people, things, skills.
>>
>> Ideally what we'd want in my view for a directory Mycelia might query is
>> one somewhat like a password manager, in which user contact info is
>> encrypted at rest to that user even to admins (as with passwords),
>> with fields invisiblizable to everyone else unless they are shared (not
>> unlike filesharing). IE a privacy token could be set for specific fields,
>> so users toggle what fields are visible to whom, or template which fields
>> are shared by default (ie email) and which fields must be manually made
>> accessible to specific users (ie celfone, home address, etc), or
>> reshareable by others, etc. I realize this doesnt exist (or does it..?) but
>> it could be useful architecture for safely sharing personal info.
>>
>> Then a way to publish/sub this db via carddav so we can have this sync
>> to our phones..
>>
>> I was looking into this the other day and in general the current state
>> of the market with respect to directory services, contact mgmt & CRM
>> still seems pretty impoverished with respect to user-settable access
>> controls and field-specific privacy, so far as I can tell: You either add
>> your (private) cel to your vCard, or you dont. No way to modulate down to
>> this level. Actually I think M$ has some basic way to do this in AD-enabled
>> GALs.. but nothing OSS-based as far as I know of, at least.
>>
>>
>>
>>
>>
>> On Tuesday, February 18, 2014, David Keenan <dkeenan44 at gmail.com> wrote:
>>
>>> This project brings up the age-old issue of transparency vs privacy. Too
>>> much 'transparency' can be bad in ways Jenny pointed out, too much privacy
>>> keeps work from being more collaborative which is endemic to the attraction
>>> of hackerspaces and collectives. In general i feel transparency is too
>>> privileged. We forget transparency often involves a loss or giving up of
>>> individual agency and control, not just a gain in centralizeable,
>>> actionable 'data'.
>>>
>>> I do think this tradeoff needs to be modulated and controlled at all
>>> times by individuals themselves. In my view there shouldnt be a repo where
>>> you are expected to list what you deem is your personal info, even matching
>>> names to 'nym's if ppl arent down for that. But i think matching nym's to
>>> projects would be useful, if folks are willing to document say what part of
>>> what project they are working on, as in dev environments. And perhaps
>>> people could set their own privacy settings, only share at their discretion
>>> certain info with certain people. I would participate in something like
>>> this if such privacy controls were part of it from the outset. Privacy,
>>> with respect to user-controllable visibility of personal info, needs to be
>>> thought of as a fundamental integral component, not an add-on, for every
>>>  software product.
>>>
>>> my 2c. carry on
>>>
>>> On Tuesday, February 18, 2014, Jenny Ryan <tunabananas at gmail.com> wrote:
>>>
>>> Oh! I should add that we could do really interesting things with our
>>> user pages, linking to projects through tags and categories, creating
>>> portals. I'd love to spend a Today We Learned working on making our wiki
>>> more awesome, semantic, navigable (Vicky? Pete?).
>>>
>>> Jenny
>>> http://jennyryan.net
>>> http://thepyre.org
>>> http://thevirtualcampfire.org
>>> http://technomadic.tumblr.com
>>>
>>> `~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`
>>>  "Technology is the campfire around which we tell our stories."
>>> -Laurie Anderson
>>>
>>> "Storytelling reveals meaning without committing the error of defining
>>> it."
>>>  -Hannah Arendt
>>>
>>> "To define is to kill. To suggest is to create."
>>> -Stéphane Mallarmé
>>> ~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`
>>>
>>>
>>> On Tue, Feb 18, 2014 at 1:29 PM, Jenny Ryan <tunabananas at gmail.com>wrote:
>>>
>>> Hey Troy! Thanks for the poke!
>>>
>>> tl;dr: Fill out your wiki userpage with current projects and contact
>>> info! Help with the membership registry (PHP) and/or mycelia (node)!
>>>
>>>
>>> ABOUT THE DATA
>>> a) I don't want everyone at sudo room to be able to call or text me.
>>> Fairly certain I'm not alone in this. If you ask for my number and I give
>>> it to you, we've just created trust through consent. Would like to promote
>>> a case-by-case approach to providing sensitive information, and not store
>>> it ourselves. This is why, when I asked for up-to-date membership
>>> information, I only asked for an email and a name/nym.
>>>
>>> b) I think we should encourage people to fill out their user pages on
>>> the wiki, and include there things like projects, contact info, and public
>>> keys. We sent out a template for user pages long ago, can't remember who
>>> put it together (Marina, I think?). Here are some examples of nice user
>>> pages:
>>> https://sudoroom.org/wiki/User:Juul
>>> https://sudoroom.org/wiki/User:Tunabananas
>>> https://sudoroom.org/wiki/User:Mk30
>>> https://sudoroom.org/wiki/User:Maximilianklein
>>>
>>>
>>> ABOUT THE MEMBER REGISTRY / SELTZERCRM
>>> I'm running the nascent member registry at http://mycelia.cc/crm, the
>>> code for which is here <https://github.com/elplatt/seltzer> if anyone
>>> wants to look and see if they can build something on top of this. It's PHP.
>>> I did a decent bit of research and this was the most viable FOSS membership
>>> registry system I could find. Soon will port it over to sudoroom.organd push to Github (hopefully tomorrow). I've been asking for help at the
>>> meetings as it would be great to have more people who want to work on this,
>>> but it needs to happen so I'm not waiting around for a team to form.
>>>
>>>
>>> ABOUT MYCELIA
>>> The goal of Mycelia <http://mycelia.cc/> is to create a decentralized
>>> database for documenting projects, people (skills) and objects between
>>> hackerspaces and also matchmaking between them. Pub/sub [publish /
>>> subscribe] model encouraging folks to have concrete projects about which
>>> they publish updates, or otherwise be a subscriber consuming the updates of
>>> others :)
>>>
>>> Unfortunately, I can't code it myself and Marc's busy with sudomesh and
>>> freestore. What's up on Github is essentially Labitrack (the QR-code
>>> sticker inventory system we're using at sudo) converted into NodeJS and
>>> LevelDB. It's definitely a priority project, but not #1 right now. CC'ing
>>> substack in case he's interested in this project.
>>>
>>>
>>> Cheers,
>>>
>>> Jenny
>>> http://jennyryan.net
>>> http://thepyre.org
>>> http://thevirtualcampfire.org
>>>  <http://technomadic.tumblr.com/>
>>>
>>>  _______________________________________________
>>
>> sudo-discuss mailing list
>> sudo-discuss at lists.sudoroom.org
>> http://lists.sudoroom.org/listinfo/sudo-discuss
>>
>>
>>
>
> _______________________________________________
> sudo-discuss mailing list
> sudo-discuss at lists.sudoroom.org
> http://lists.sudoroom.org/listinfo/sudo-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sudoroom.org/pipermail/sudo-discuss/attachments/20140218/06c9ca48/attachment.html>