[Noisebridge-discuss] access for members and associate members at all hours

Naomi Most pnaomi at gmail.com
Mon May 12 23:51:40 UTC 2014

> You are relying on an undefined trust model, and a model
> that frankly seems to rely on trust relationships that
> do not exist.

We know.  That's what we're working on.


On Mon, May 12, 2014 at 4:42 PM, openfly
<openfly at xn--kgbed8a0h.xn--ngbc5azd> wrote:
> Two key points.  Argue their veracity amongst yourselves if you must.
> 1.  Kicking people out of the space as a method has failed
>     utterly for the past 4 years.  Some seem to think that
>     THIS TIME it will work.  I can only point out that
>     experience would suggest that you are very very wrong.
>     The reasons for this could be many.
>       a) Few people with the will to risk a physical
>          altercation
>       b) Lack of identifable and functional trust
>          relationships in the noisebridge trust model.
>       etc etc.
> 2.  The Noisebridge membership structure is not a functional
>     trust-model for the space to rely upon to enforce any
>     trust relationship based authentication mechanism.
>     In short, you have too many members / associate members
>     to reasonably expect folks to track who brought who in
>     and is responsible for whom.  More to the point, this
>     model relies on an implicit trust of all members and
>     associate members of noisebridge.  Something that
>     frankly I see no grounds for believing exists.
>     Now get angry all you want and spout on about your
>     hopes and dreams for a better noisebridge but it's year
>     seven or so.  If you keep repeating the same mistakes
>     you MIGHT consider the posibility that some of your
>     fundamental premises may be built upon flawed logic or
>     theories that have not faired well in experimentation.
> I guess what I am saying is, you guys are talking about
> building filters to stop an undefined element of noisebridge
> visitor.
> You are relying on an undefined trust model, and a model
> that frankly seems to rely on trust relationships that
> do not exist.
> I'd recommend..  simple logical analysis here.
> Drop your emotions off at the local burrito palace and
> let it down a jarritos while you do this.
> Work on defining these:
> First the firewall style logic ( easy ):
> 1.  Is the access filter to noisebridge a default deny or a
>     default allow?  ( I assume most want a default allow )
> 2.  Who are you specifically excepting ( allow or deny )
>     from the default filter rule?  Define the folks who
>     are exceptions from the default rule.  All of them.
> Now stop for a second.  Give that a look again.  Grab a coffee
> or a tea, maybe a yerba mate.  Relax.  Ponder.
> Now for the next part...
> Think Trust relationships ( moderately hard ):
> 1.  What relationships of trust currently exist in Noisebridge?
>     Do members trust other members?  Do members trust associate
>     members?  Does anyone trust a visitor.  Can you quantify
>     a metric of trust as a numeric value?
> 2.  Take the list of exceptions you developed in the first part,
>     draw lines between them where a trust relationship exists.
>     Add a numeric value if you can.  If there is no trust
>     you can probably still draw a line just... broken and red or
>     something.  That's a high risk relationship right?
> Cool.  Again.  Time to let the brain cycle down a bit.  Maybe
> go grab a burrito with your emotions for a bit.  Or a tasty
> pastry.  Hell be healthy and go do your evening or morning
> exercise routine.  Meditate.  Just get your mind to take a
> breather.
> When your done, come on back next step.
> The Trust Model ( Actually hard ):
> 1.  Draw up some models for how the trust relationships work
>     currently.  Do some flowcharts for examples of scenarios.
>     What happens when a default set enters.  What happens when
>     a member enters.  How do they function once inside?  What
>     mechanisms might exist that use trust relationships as
>     a vector or argument?  Start building some lists.
> Do number 1 for a while.  Lots of scratch work.
> Get a feel for what's going on at noisebridge today.
> 2.  Look at what's been tried in the past same as you did for
>     the present.  Draw out the flow charts.  Identify trust
>     relationships that played a role in mechanisms and
>     notable real events.  Flag stuff that didn't work.
>     Weight it if it's a repeat occurrence or particularly
>     dangerous.  Quantify that into a number if you can.
> Okay.  This is getting really harsh now.  Hope your emotions
> haven't finished their burrito and come back drunk looking to
> get surly.  If they have maybe go home for the night and let
> emotions sleep it off.  The next part requires you to be zen
> like even.
> 3.  Come up with some hypothetical fixes.  New trust
>     relationships.  New mechanisms.  See how they
>     might work using your past flow charts.
>     Work with weights if you have em to set
>     priorities.  See if you can use the trust-relationship
>     quantified value to improve mechanisms or filters.
>     Try new filters.  Swap from default deny to allow or
>     vice-versa.  See what happens when you do.
> This part is kind of fun if you can separate yourself
> from drama or emotions relating to it being anything more
> than an abstract model you are playing with in your head.
> Be creative.
> 4.  Now, here's the bees knees if you can do it.  Try to
>     take all of your work and build a trust model that
>     is an improvement to what noisebridge is currently.
>     New mechanisms, new relationships and weights, new
>     filter sets.  Propose something that is an improvement.
> Now...
> At this point.  Then we can have this discussion properly.
> Like real live engineers.
> Jah rule yah jive ass hackers.
> -openfly
> _______________________________________________
> Noisebridge-discuss mailing list
> Noisebridge-discuss at lists.noisebridge.net
> https://www.noisebridge.net/mailman/listinfo/noisebridge-discuss

Naomi Theora Most
naomi at nthmost.com

skype: nthmost


More information about the Noisebridge-discuss mailing list