← Back to team overview

wintermute-devel team mailing list archive

Re: Subminds and Encryption.

 

On Tuesday, 10 May, 2011 05:12:58 PM you wrote:
> Hello Jacky
> 
> Two things;
> 
> First, remember how we were looking into encrypted files a while ago? I
> found a program in Ubuntu called the GNU Privacy Assistant. It'll let us
> encrypt and decrypt files, so if there is anything we need to protect
> whilst sending to each other, it'd be handy...

Yup, but KDE has KGpg and my keys show up in it. Dolphin supports the 
decryption and encryption via a service, pretty nifty.

> 
> Secondly; I had an idea for another function of Wintermute; I call them
> 'sub-minds'; smaller, lighter, and less resource hogging then Wintermute.
> It's like a mini-me Wintermute could construct and equip for a number of
> purposes;

Now, when I think of a sub-mind, in terms of implementation, I think of the 
BackTrack OS. Yes, that network penetration system. It's because the 
system's not designed to be installed anywhere. That's one plus, except 
that we'd like sub-minds to be able to physically carry information back to 
Wintermute, no? Also, the system has a pre-configured purpose, to accomplish 
Z by doing A, B, C and D. 

We'd need to create some sort of interfacing capability for Wintermute so 
it can detect whether or not if it created this sub-mind (easily done with 
a list of the drive UUIDs). It could further link foreign sub-minds to 
other Wintermutes that it knows. Case examples:

1) "The inserted sub-mind is from the Wintermute Developers team, an 
trusted source. This sub-mind provides critical system upgrades, including 
security, semantic and linguistics updates to Wintermute."

2) "The inserted sub-mind is from your friend, Karen, who wishes to import 
modifications to my appearance. Do you want to see a video she attached? 
It's about 2 and a half minutes long."

3) "The inserted sub-mind is from an unknown source. It's requesting 
permission to transfer all of your information to a remote source. Grant 
authorization to this device?"

Device authorization could be a whole another aspect of Wintermute's means 
of communication. If we consider sub-minds as members of an AngelNet, then 
the trust system could be exploited there to provide even more security and 
configuration for sub-mind devices. Sub-minds, of course, could be even 
mounted from ISOs (since ISOs can be mounted as a CD/DVD) and such a set-up 
could be for ... God knows what?

One thing about the sub-mind system; it'd have to run off a set of pre-
configured commands. What better to manage such a process than daemons. A 
daemon instance of Wintermute would only provide the raw minimum of 
Wintermute's abilities (this of which is currently linguistics parsing, 
ontology parsing and (if network capable) AngelNet connectivity). 
Currently, this pulls in about this many dependencies:
  Depends: libboost-program-options1.42.0
  Depends: libboost-python1.42.0
  Depends: libboost-signals1.42.0
  Depends: libboost-system1.42.0
  Depends: libc6
  Depends: libgcc1
  Depends: libncurses5
  Depends: libpython2.7
  Depends: libqt4-dbus
  Depends: libqt4-network
  Depends: libqt4-xml
  Depends: libqtcore4
  Depends: libqtgui4
  Depends: libsoprano4
  Depends: libstdc++6
  Depends: libwntrdata
  Depends: libwntrling
  Depends: libwntrntwk

The total size of the packages come up to at least 45 MB (and that's just 
guessing), so the minimal sub-mind system would be around 50 MB to 70 MB 
just for introducing itself. We could have a introductory sub-mind on first 
install that could be easily deleted for users to learn how to get 
accustomed to Wintermute.

> 
> First off; think of a diagnostic submind; a smaller version of itself,
> designed to go in via USB keys into a system to diagnose and (hopefully)
> repair the system, somewhat automagically. With limited speech
> recognition and nothing in the way of an ontology,

The above list doesn't even include speech synthesis and recognition sizes, 
that would have it skyrocket with 200 MB+, still under 400 MB, but it's 
pretty chunky. One thing about Wintermute, the ontology it contains, I'm 
predicting would be about 8 - 15 MB at minimum with all of the knowledge it 
needs to present itself, like a fresh install. Speech recognition would be 
optimal and of the same quality of a desktop install, unless we really 
would need to bring down the size. We should have Wintermute spawn sub-
minds that use the same voice as its parent, just to make this more 
naturally efficient. A level of proficiency should be shown to the user (from 
weak to strong) in terms of its speech abilities before production, as to 
give them a choice (a F/LOSS ideal!)

> it'd simply be be equipped to go into a system, diagnose it, try and 
repair it if it can,
> then return to Wintermute to be subsumed back into it, all information
> it collected becoming accessible to Wintermute, as the sub-mind becomes
> part of the main program.

With the sub-mind setup above, Wintermute should be able to do this with 
proficiency, and perhaps refine the sub-mind to go back in there. The only 
thing I see a problem is installing packages onto a Debian system that's on 
a different partition. Never seen it done before, but a simple wget script 
could be made (or something more semantically friendly).

> 
> Another such use could be that of a general version of Wintermute, for
> less powerful machines; designed to go onto a USB stick or old/weak
> computer and act independently, or in tandem, with the main Wintermute.
> (Particularly for devices like mobile phones/tablets) but without most
> of the ontology or certain functions removed.

Now, we'd have to see what features would be needed to be removed from 
Wintermute to achieve this. I'm assuming we can drop all of Boost and just 
use a configuration file, drop Python support and leave it at that as best. 
Everything else is needed for linguistics and semantics. 

Do keep in mind, we haven't even begun to implement the evolutionary 
heuristics for Wintermute.

> 
> And again, another use could be that of a sub-mind dedicated to a
> specific area of knowledge. Let's say Stacy went off to do some research
> for her school project on Ancient Egypt, for instance. This submind, on
> her USB stick, starts collecting and organizing all the data it can
> find, present it to Stacy, (and present it to the larger, more
> 'reasoning' main Wintermute installation to ensure it was the proper
> data) and perhaps even prepare a small speech for her to read out the
> information to her class.

I don't have enough information for this scenario. Is the sub-mind on the 
USB shipped out to school with Stacy, away from the primary Wintermute?
Is that where it gets information? Does (or better yet, should) it collect 
preliminary information from Wintermute about what to look for and how to 
organize it? I can see the speech being generated by the core Wintermute 
process in the background and presented when completed, but I guess having 
it generated at school would be cool too.

> 
> Going even further; imagine Stacy has her own laptop, separate from her
> parent's desktop computer. Her machine may have a sub-mind dedicated to
> her catered to her interests and age. Considering it's a laptop, it
> would also be 'seperate' from the main Wintermute installation on her
> parents computer.

Okay, now with this info, the sub-mind itself becomes a full-fledged 
Wintermute, or rather, a sub-mind that's monitored by the desktop 
Wintermute? Either one could be done, but it wouldn't be a sub-mind in the 
sense of a sub-mind as described above.

> 
> 
> What do you think?

I think that we're headed to pretty interesting areas of computer science. 
If only I could freaking get my own system with Internet access, only 3 
hours a day would be needed! lol

Attachment: signature.asc
Description: This is a digitally signed message part.


Follow ups