[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [GMG-Devel] Plug-In Development Prerequisites
From: |
Alex M (Coyo) |
Subject: |
Re: [GMG-Devel] Plug-In Development Prerequisites |
Date: |
Sat, 13 Apr 2013 18:23:38 -0500 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 |
On 04/10/2013 09:49 PM, Alex M (Coyo) wrote:
There are a few specific plug-ins I am very interested in developing.
1) Active Directory Authentication
(LDAP + Kerberos + DNS, by way of SAMBA) Active Directiory plugin for
unified user authentication among multiple mediagoblin instances
within a site domain. Useful for use cases involving multiple
mediagoblin instances that are not synched with a single database.
I suppose I could use plain LDAP or a personal form of LDAP + Kerberos
and/or Radius, but I need the samba active directory experience anyway.
2) Social Network Federation
StatusNet/OStatus/PumpIO social network federation, possibly with
Diaspora/TentIO and Friendica/Zot/Red protocols on the distant roadmap
with the same python federation library.
I suppose we could start with PumpIO implementation.
I'm not a fan of javascript, though I AM a fan of the asynchronous
event-driven actor model.
It makes it really really easy to quickly code P2P network applications,
scale up virtually as large as you could want, and since actors all act
independantly, it's fairly straightforward to add 0MQ+MsgPack RPC to
permit interprocess communications between machines.
I wish an equivalent framework existed for python. Before you say it,
Twisted is ***NOT*** an equivalent framework, it's not even a framework,
and it's not asynchronous, must less actor-oriented.
The only real similarity is the existence of a Reactor object. That's
about it.
3) Extended Social Functions
Specifically: journals, submission feeds and pub/sub, distinct
submission channels (sub-contexts), threaded comments on submissions,
submission replies (reply to a submission with a submission), interest
groups and sub-communities (user groups you can submit media and
journals to, in addition to microblogs and commentary)
These features are 100% mandatory if the mediagoblin project wishes to
be a serious influence on the Internet's openness and liberty.
4) Integrated Chat
(via libpurple) Extensive chat, including groupchat. Would preferably
be tied to a chat server hosted by the same domain (or a sub-domain).
Preferably would include voice and video chat, but obviously that
comes after textual group chat. May automatically manage and
instantiate skype group chats with skypekit running over wine.
We can argue all month about Skype's proprietary nature, but until I see
a real alternative, in other words, trivial (and free) group video over
IP, no FOSS project is really an alternative. Asterisk is awesome, but
the conferencing features are extremely limited, group voice tends to be
extremely taxing on the server, SIP in general takes a very naive and
crude approach to NAT hole punching and stateful firewall circumvention.
SIP just sucks in general.
Jingle will never be a serious alternative, I think. MuJi (Multiparty
Jingle) is at the absolute bottom of the priority pile, and XMPP/Jabber
developers are lazy bums.
They have irritated me to the point where I am tempted to develop a
0MQ+MsgPack RPC version of the XMPP protocol and add a ton of
proprietary extensions for the sole purpose of annoying and excluding them.
How this would work is re-implementing the core jabber/xmpp
specifications in the relevant RFCs and core XEPs, but throwing out XML
wholesale, giving the existing xmpp federation the finger, and pointedly
discarding the concepts of "standing on the shoulders of giants,"
"maintaining compatibility with older clients," "maintaining
compatibility with the xmpp federation," "enforcing human-readability,"
and "enforcing strict exclusive text-only protocol openness."
Instead, we'd take a very aggressive and deliberate
compatibility-breaking attitude and approach, making the protocol pure
binary-only, deliberately and pointedly relying on specialized libraries
for protocol implementation, deliberate and pointedly overt avoidance of
using XML, JSON, BSON, Bencoding or any other high-level abstracted
serialization format for anything.
We'd give users, admins, and plugin developers the freedom of tunneling
JSON or whatever within message buffer objects passed as a parameter
within the binary RPC protocol if they are that much a bunch of
masochists, but that doesn't mean we won't laugh at you for doing so.
Though, considering how lazy the XMPP developers are, I could release
the nonstandard extensions as AGPLv3 and simply not fully document it or
fully comment the source code, and chances are they won't bother to
reverse engineer the protocols. They can't be assed to work for a living.
It also doesn't help that XML streams, end-to-end stream encryption,
encryption in general, absolutely anything P2P or security-related,
anything related to social networking (BuddyCloud is being developed so
excruciatingly slow as to be barely worth mentioning), and the
dependance on TLS PKI is beyond naive, recklessly endangering every
jabber user in existence.
DNSSEC, DANE, DNSCurve and DNSCrypt would make certificate authorities
(who have a long and disgusting history of betraying their clients and
their clients' users by traitorously submitting like little sheepish
cowards to demands by the State to collaborate in warrant-less domain
seizure, wiretapping, traffic interception and outright blatant
certificate forgery, unashamedly and unapologetically abusing their
position of trust. Cowards and traitors, all of them. Bunch of
traitorous cowardly bums, every last one.
With DNS extensions such as those previously mentioned, it would be a
lot more difficult to forge certificates, interfere with zone answers,
deceive or subvert naive users or server admins, or otherwise abuse
their power, trust, responsibilities and authority.
At least with DNS, it's a lot easier to simply deploy your own
alternative root, mirror ICANN TLDs and their authoritative nameservers,
deploy your own tier 2 caching resolvers, and use nonstandard extensions
and protocol obfuscation to resist subversion, coordinated state-level
attacks and various attempts at denial-of-service, man-in-the-middle,
sybil or infrastructural attacks and subversions.
So, bottom line, the TL;DR version of my argument regarding skype and
the FSF's naive attitude toward dynamically linking to non-free
libraries, shared objects or frameworks is basically,
"You have something better? No? Then STFU and GTFO."
"Give me an alternative, or get out of the way."
The only real alternative to skype is an equivalent decentralized and
P2P attack-resistant, censorship-resistant and privacy-protecting
overlay network that is low-latency enough, secure enough, resilient
enough to NATs, stateful firewalls and IDSs, and efficient enough to
support:
* Distributed P2P group voice and video chats
* Teamspeak/Mumble-like serverless decentralized P2P game-oriented voice
telephony
* Distributed P2P SocNet (FOSS alternative to Facebook, DeviantArt or
YouTube, basically a scalable P2P version of MediaGoblin)
* Distributed object storage, P2P filesharing, virtual distributed
versioning filesystems, and scalable low-latency data stores
* Trivial decentralized VPN tunneling (P2P FOSS alternative to hamachi
or remobo)
* Screen-sharing, remote access and control, remote administration and
management
* Resilient and secure SSH authentication
* Fully-feature-packed instant messaging with extremely scalable
distributed chat rooms (infinitely superior P2P alternative to IRC,
Jabber, Zephyr, Bonjour and PSYC, as well as any conceivable non-free
protocol or network)
* Distributed forum-like threaded discussions (superior P2P alternative
to mailing lists or web forums)
* Distributed P2P MUD/MUCK-like massively-multiplayer serverless online
roleplaying games and/or virtual worlds with more features and
scalability than either secondlife or over-provisioned opensim grids
* Extremely efficient layer-2 switched hardware-accelerated overlay for
the wholesale disposal and replacement of DNS, Ethernet, TDM Optical
Carrier, SONET, IP, BGP and any need for centralized address space or
ASN authoritative allocation
* Extremely efficient ECC public key based layer 2 switching fabric with
IS-IS-like and TRILL-like behavior with no distinction between layer 2
and layer 3 addressing. ARP does not exist, broadcasts do not exist, any
distinction between residential, business, enterprise, service provider,
carrier and content provider networks or protocols do not exist
* Absolute and explicit eradication of HTTP, SOAP, XML, JSON, the Web in
general, port numbers, centralization of any kind, hierarchical network
structure, authoritative named entities, any possibility for state
privacy breaches or abuses and any distinction between client and server
roles.
With these features, you would not need skype, or any of the crap that
holds the Internet back (and yes, the Internet Protocol itself is to
blame, along with HTTP, TCP, BGP, and Ethernet)
If you created a layer 2 overlay-style switching protocol, and
eliminated the distinction between framing and packet forwarding,
combining layer 2 and layer 3, pointedly and disgustedly throwing out
the OSI model in the process, and instead used a more MPLS + TRILL +
IS-IS style switching protocol, replacing all MAC or IP addresses with
ECC public keys and integrating a P2P WOT-style certificate verification
and revocation as an integral and mandatory protocol in the core
protocol stack, while integrating heavily modified MPLS/CJDNS,
TRILL/LISP, IP Multicast, and integral IS-IS-style routing into a single
unified and cohesive protocol as part of a larger cohesive core protocol
stack.
End-to-End tunneled ECC is a mandatory core feature, and switched
MPLS-style over a TRILL-like minimal point-to-point line protocol.
Mandatory and universal use of ROADM DWDM with advanced compression and
optical channel multiplexing (such as using really advanced bit-coding,
polarization multiplexing means that bandwidth is rarely a concern.
Anyway, if you are interested in my ideas for a wholesale replacement
for the Internet's core protocols and flaws, poke me at my email
address. I'm going to visit a CCIE-certified senior network engineer
friend of mine at his townhouse. See ya!
Re: [GMG-Devel] Plug-In Development Prerequisites,
Alex M (Coyo) <=