So this isn't a ZOMG let's declare RFC 31337 and bind the world to our protocol conversation. At this point for me it's an exercise in automation, which is... well it's fun. Let's be honest.<br><br>So, I figure John you are right on the same track I am. You are thinking well, what is the flow chart for accepted protocol used for providing access to a foreign exchange hacker.... on a one off short term basis.<br>
<br>And what I am seeing is that the requirements for this range from the highly awesome "hey come on in, why that's a lovely axe you have there, is that red paint?" to "don't answer that... he didn't knock with the secret sequence of knocks." We can't really work around that. People are going to decide their own level of security thresholds. That's up to them.<br>
<br>What I do however take away from this thought process is that, hackerspaces are organizations defined by their members. And the sort of security / non-security requirements that exist for any social group will be of course of their own design.<br>
<br>Fine. So maybe the solution to the passport question isn't defining a protocol of "use" but defining a method of establishing identity quickly and cleanly while affording everyone who participates the highest possible level of self determination in use of their own data as well as security.<br>
<br>And the reason at this point I get even a little excited, is because a system of that nature is directly applicable to security and privacy oriented social networking. And if you can establish a simple protocol for defining trust relationships and pushing simple contact info... <br>
<br>It could be pretty huge. Digital business card sharing. Integration to well... anything you want. +open hardware would equal some pretty sick integration all over.<br><br>Maybe I am nuts. But if it was tied to gpg... you could use it to gpg the world's email finally.<br>
<br>Just pondering.<br><br><br>So imagine... a small mcu with some sort of simple active interface ( rfid? pin contact? ) hell... maybe just use cell phones and an app. Or maybe both. Define the spec to work in soft or hard deployment. Let people establish their own social orgs and members of those orgs. Let people basically assign their trust to people. Then allow people to view their trust keychain... or just look for intersections in their social network and display those only. <br>
<br>It's pretty cool dynamic trust implementation stuff. If you got it down to a tiny physical token / cell app it could be damned useful. Especially since there is no central authority.<br><br>-Matt<br><br><div class="gmail_quote">
On Mon, Jun 13, 2011 at 11:41 AM, john arclight <span dir="ltr"><<a href="mailto:arclight@gmail.com">arclight@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
There seems to be a de-facto process, at least with us.<br>
<br>
1. We get an e-mail that says "Hi! I'm a hacker from out of town. I'm<br>
going to be in <your city> on <this date>. Can I come hang out?<br>
<br>
2. We get an e-mail that says "Hi! I'm a hacker from out of town.<br>
<Person that you know> said you guys are cool and that I should come<br>
by your space. Can I come hang out?<br>
<br>
3. We get an e-mail that says "Hi! I'm <person you know from mailing<br>
list X>. Can I come hang out?<br>
<br>
Yes, we're talking unauthenticated SMTP communication and unverified<br>
references. But we have yet to experience a problem from someone<br>
referred here by any of these ways. I'm probably more open to letting<br>
folks crash here overnight if I already know them or have good<br>
authority on them, but I can't see any situation where I'm going to<br>
turn them away from hanging out with us.<br>
<font color="#888888"><br>
<br>
Arclight<br>
</font><div class="im"><br>
On Mon, Jun 13, 2011 at 5:55 AM, Ross Smith <<a href="mailto:rsmith@i3detroit.com">rsmith@i3detroit.com</a>> wrote:<br>
</div><div><div></div><div class="h5">> The reason I would never support a hacker passport is that it would involve<br>
> me refusing hacker guests who don't possess one.<br>
><br>
> Seriously, unless someone is going to be in my space, consuming its<br>
> resources at the expense of my membership for several weeks, I don't see any<br>
> problem with a completely informal system. If a visiting hacker will<br>
> require the resources of my space in that way, we'll work out an ad hoc<br>
> agreement. It certainly doesn't happen often enough to be a systematic<br>
> problem requiring a systematic solution.<br>
><br>
> Rules are bad; we only need them when the problems are worse. As such I<br>
> rejoyce at the idea that hackers cooperate on the basis of being intelligent<br>
> people rather than participants in a system.<br>
><br>
</div></div><div><div></div><div class="h5">> _______________________________________________<br>
> Discuss mailing list<br>
> <a href="mailto:Discuss@lists.hackerspaces.org">Discuss@lists.hackerspaces.org</a><br>
> <a href="http://lists.hackerspaces.org/mailman/listinfo/discuss" target="_blank">http://lists.hackerspaces.org/mailman/listinfo/discuss</a><br>
><br>
><br>
_______________________________________________<br>
Discuss mailing list<br>
<a href="mailto:Discuss@lists.hackerspaces.org">Discuss@lists.hackerspaces.org</a><br>
<a href="http://lists.hackerspaces.org/mailman/listinfo/discuss" target="_blank">http://lists.hackerspaces.org/mailman/listinfo/discuss</a><br>
</div></div></blockquote></div><br>