[Noisebridge-discuss] access for members and associate members at all hours
openfly at xn--kgbed8a0h.xn--ngbc5azd
Mon May 12 23:42:30 UTC 2014
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
b) Lack of identifable and functional trust
relationships in the noisebridge trust model.
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
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
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
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.
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.
At this point. Then we can have this discussion properly.
Like real live engineers.
Jah rule yah jive ass hackers.
More information about the Noisebridge-discuss