I just stumbled across http://terriko.dreamwidth.org/151005.html
Since I frequently hear that mailman is a spawn of Satan if not Satan
Incarnate himself, it might be of interest to take a preliminary look.
> it just proxies whatever normal public dns you tell it to....
Presumably they seed the namecoin table with DNS records and use those
instead when they exist? I don't know whether those can be expired
> As for on the current web making sure you're sending
> your password to the right person, no one is intercepting
> your credit card details, who you're talking to isn't being
> tracked by anyone but the site itself, etc... well okTurtles
> just leaves that up to the same certificate authorities
> they don't trust....
It seems like they would take the next logical step and verify
namecoin-cached public key ﬁngerprints of both the site and the
certificate before initiating a traditional SSL connection (and/or
better revocation support.)
Daniel Friesen wrote:
>... The okTurtles/DNSChain authors...
> make ridiculous statements like "It depends on group
> consensus, but the group might not be very bright. What
> happens then?"....
While I agree with much of Daniel's analysis, that part was actually
the most compelling of all the arguments against convergence.io,
except for the part about okTurtles/dnschain accepting multiple
passwords which decrypt the same cyphertext to different data sets,
And that part is more than compelling enough for me to remain
convinced that okTurtles/dnschain is superior to Convergence.
I enjoyed the https://www.youtube.com/watch?v=Z7Wl2FW2TcA
video because I used to sit 10 meters from Kipp Hickman at Netscape
when he was adding certificate authorities to SSL. I remember him
joking about it in the hallway, right next to the letter from the NSA
which said Netscape would be in trouble if they didn't comply with
various demands which someone had pinned up across from Dan Mosedale's
cube. Five years later I was reviewing CALEA compliance documents at
Cisco. I wonder what Mosedale wants to do for DNS these days.
We've gotten some feedback already -- https://github.com/SemanticMediaWiki/SemanticMediaWiki/issues/212 -- about the RC for MediaWiki 1.23 that Markus made last week. Hopefully we can get this issue addressed in time for SMW users.
Are there any other issues that people have run into that we should know about before we do attempt to make a final release of 1.23?
If you've tried the RC and not run into any problems, that would be good to know, as well.
I think it would be fine to skip the IRC discussion (for Requests for
Comment review) that would happen on Wednesday, May 7th, because so many
potential participants will be in transit to Zurich. You are, of course,
free to schedule your own meetings to discuss things, if you disagree. :-)
So, I'm seeking out proposals to discuss ~May 14, 21, and 28. Feel free
to ping me personally or set something up linked from
https://www.mediawiki.org/wiki/Architecture_meetings . Some suggestions:
Content API, Knockout, Storage service, Clean up URLs, URL shortener,
Json Config pages in wiki, API roadmap.
Senior Technical Writer
Hello, and thank you for your work,
I was looking at the Librivox project today and I thought that it'd be
great to have voice support in Mediawiki, to aid people with sight
impairments or disabilities.
So I was wondering whether there is a text-to-speech extension for
Mediawiki, or if there could be some other means of offering wiki pages
in audio form.
Thanks for your time as well,