.
FRDCSA | internal codebases | Audience

Audience Architecture Diagram: GIF

Jump to: Project Description | Capabilities

Project Description

Since this description was last modified there have been major additions to the audience system. The primary system is an IMAP client that is able to read mail and queue actions based on programmatic responses to the mail. The reasoning and usability behind this is still at a primitive state but I've written a set of filters (actually belonging to the antispam-console system but should be refactored into audience). At any rate it is interesting because the system is now at a more advanced state. I suppose it would not hurt to allow encryption of these email messages.

Capabilities

• audience should use LDAP for identification.
• audience should integrate with LDAP.
• In fact antispam console should simply be a filter for audience.
• For audience, create a bayesian filter for parsing mail.
• Write my own curses based email client for use in review messages. as part of audience.
• Read me things in the background through clear, like audience emails.
• audience should function together with dbmail and rmail, as a mail client.
• audience - Before responding to a message, consider that your understanding of the message or at least the intent of the writer may not have been correct in some or all ways, hence should not respond immediately.
• audience should record which mail messages need to be responded to.
• audience should use dbmail as the backend for mail storage.
• audience should possess tact.
• For instance, audience is great, but it lacks the ability to introspect, so as to see when its reasoning will not succeed. That introspection of arguments is going to be necessary as part of planning. It is theorem proving on a plan, and that is essential. I am glad I realized that. To think about whether or not something will work. What program thinks about a problem, searches for any problems, works with it, then tries to carry it out and so forth.
• Use LDAP or something for audience identity management. Use mnop to identify hidden people (if necessary?)
• /var/lib/myfrdcsa/codebases/internal/unilang/start audience broker clear corpus cso ELog manager OpenCyc pse unilang-Client
• Develop part of machiavelli that learns user interest. Proxy through audience.
• Should act as a scratchpad for audience.
• audience should make more use of the letter authoring system.
• Develop talking points system (within audience)
• Use an event system and formally model requests through audience.
• Obviously spark is useful for audience, and many other things.
• /var/lib/myfrdcsa/codebases/internal/unilang/start audience broker clear corpus cso ELog OpenCyc pse unilang-Client
• audience should not just have email support, but also conversation planning support. Could work multiparty.
• General the contact features of manager to any agent... and then use the audience tell told stuff. In fact that is the basis for the AA.
• Use classification/sanctus for audience/diplomat/opsec
• Just occurred to me that books etc probably have a noticable context trailing system that audience could use to measure output.
• audience could keep track of what issues are alive or dead until certain times, ever, etc. For instance, DSL is dead for certain reasons. Changing AOL as well.
• Just now I imagined accidentally dying at my computer, and that my computer would say, "Andy, are you there?" and some time later repeat itself. Afterwards it would conclude that I wasn't and try to contact a friend of mine to see where I was, but it would conclude there was no way to access them (no networking etc). That could be how manager/audience work a little bit.
• Write subsystem of audience (or maybe fieldgoal or boss) to catch up with other developers
• audience should store its information in a researcher page in machiavelli
• reasonbase can use existing IM logs to find plenty of examples of arguments, and build an audience dialog system based on that.
• unilang agents should, defined through audience, have a nominal state that allows unilang while dynamically starting them upon messages received for them (so they don't all have to start at once), that indicates they are ready for processing.
• Actually we should eventually factor out the manual code that is making the classifications, and replace it with manager::Dialog code, so that the whole system is more complex. And, to boot, we should replace manager::Dialog with audience, so that everything is smarter. audience should use theorem proving to determine which context it is operating in.
• Actually, we should eventually factor out the manual code that is making the classifications, and replace it with manager::Dialog code, so that the whole system is more complex. And, to boot, we should replace manager::Dialog with audience, so that everything is smarter. audience should use theorem proving to determine which context it is operating in.
• audience should convert to either using SQL or something. In general, we should have a flexible system for wrapping between any of these.
• Could use spark as my task model and use it more than just for say, audience.
• Should simply implement the remaining audience functionality in order to have control over interns.
• Here are some of the things I could work on. I could integrate spark into audience, so that it acted on telling people things, etc.
• Can use machiavelli in combination with audience and various requests to estimate social network.
• In the future audience should automatically tag threads using TDT.
• Fix audience bug where it logs off but doesn't think it has.
• Would be nice for the systems to know various interfaces, for instance, if audience is asking the user something, then it should necessarily use the expert system for generating interfaces that manipulate data.
• I mean sometimes audience might not need to verify receipt, but it should for important matters.
• Note that currently audience is subject to switch receiver on you without noticing, and you could make many mistakes that way.
• Fix the problem with audience screwing up on anything but a commnad
• We can have agents print things like <audience: > using a library that we replace all print statements with, maybe even redefining print to make it easier.
• Here are some informations: we can write a program that "negotiates" with Dad, making him agree to certain propositions before he is routed to me directly. Secondly, audience should support the notion of one contact using another contacts IM.
• People are more responsive to you went you give them time between seeing you - therefore, calculate their responsiveness using audience or mach and use this as a decision aid.
• Using audience of course.
• I can use audience to log when people have logged in or out.
• Should be able to start an agent from this window, have a unilang, start agent audience, type feature.
• audience should keep track of which letters from the LAS I actually intend to send.
• audience should learn which people we have rapport with and which we don't, like a neuron.
• audience can automatically write people we need to talk with to obtain information. Suppose I have a question about doing ontologies in Perl, it can automatically post this or send email to the person who does this most... etc.
• Another idea just popped into my head, and then popped out. There it is, RSR/audience can send you warnings to end the conversation, and in the worst case do an emergency termination.
• Some more ideas for audience - of course it should regulate interaction in many ways - another things it should do is that if you are talking with people on IM (this being permitted by diplomat and RSR in the first place) Yeah - that's great - RSR can act as the guardian - approving various things.
• Due to having to many good ideas I must keep writing. audience should regulate my usage, and if I am talking to much - oiniinitiate the end o fthe conversation.
• audience will provide a framework in which to test empirically various communication strategies.
• Might call them roles instead of identities in audience. Should take on different roles - like president of the chess club.
• audience should prioritize messages, in addition to summarizing, annotating and routing.
• Just had an idea for something - audience could determine who you were talking to and route it to them for this complex IM conversations.
• Suppose Dad had sent me a nasty letter, that audience had stored it, and that I knew about the letter. What would stop me from, out of curiosity, looking at that letter? Perhaps we could compile a program that would plan creative ways of hiding the encryption key to that data. Furthermore we'd have to make sure I could not simply reprogram the program to give it to me without the necessary approval, nor could I forge the necessary approval.
• In the case that someone asks to find me, some delay should naturally be put in so that they cannot determine that I am here, unless we want them too. One might note that there should be agreed upon settings between agents, such that, supposing Person A doesn'doesn not want person bB to access their information X, then when they share X with C, it must be on that persons promise not to share it - both through audience, and that persons own promise (for other means of communication. Additinoally, when trying to determine the leak - use different formulations. This will aid in an axiomatic model checking methods for leak detection. That should be built right into audience.
• I can see now long chain events like Something happening -> verber -> event-log -> audience -> machiavelli -> audience -> (internet) -> etc.etc.etc.
• By textual analysis of what clear and now audience are storing, it should be easily possible to query the system (running the question askers for each person's data, perhaps dynamically, or somehow) what they should know and behave accordingly. Would help to have more content area specifications as per fieldgoal
• Maybe should create a one liner format for audience messages so they don't hog the screen.
• Secondly - audience should do the classification of what events are interesting, I believe anyway at least for now.
• audience itself should really decide what events to listen for.
• audience should make should that nothing that was told to anyone gets repeated unless intentionally.
• I have to email this one kid some chess info, but only feature not yet implemented for audience is sending mail.
• We can mine other people's logs to get an idea for what is appropriate, audience can recommend to us what is appropriate.
• audience should support file transfers and voice.
• audience should speak its own format, and thus be able to communicate with itself.
• audience should aid in tracking who knows what pieces of information. For this system, also note how the message was sent and therefore what classes of people know about it.
• Possibly use celt as a system for keeping track of things over audience.
• Deregister audience
• Some things to keep in mind - if someone has no permissions to talk with audience, should we block them or just ignore them?
• Some of the features for audience that have emerged, first, you can have a phone interface that will call people.
• audience will be necessary for job-search, and even manager if I recall correctly.
• audience is an important application. It's probably not the hardest to write of course.
• audience needs to interface with verber, and specifically, do conformant planning over communication acts.
• It was because of removing gaim that I wrote audience. I have to back this thing up.
• audience should correct for common name substitutions, prompting in severe cases.
• audience should work to expose fallacies, in coordination with the Legal reasoning system.
• audience was already a good system, and now its even better.
• audience can use my extensive personal writings to compose arguments.
• It just occurred to me that audience out to be able to generate Conversation maps.
• audience may make use of bard for generating a satire!
• Don't forget to add to audience the stuff I've always wanted to see, like automatic testing and probing of social networks.
• Obviously encryption falls under the responsibility of audience.
• Note that we must track rapport, its pretty easy, when someone becomes defiant, to note this, and to seek ways to regain rapport. That is clearly audience's job.
• Use spark for audience
• audience can use question classification to present queued questions from others with contingent response choices (yes/no, multiple choice, type,etc)
• This functionality should be distributed between audience and event-log
• Apparently - post-el may be related to audience
• Use enron dataset for audience illocutionary force determination.
• Obviously, audience communication should be formalized in MBP.
• I think I must have had a dream about finishing a major part of audience.
• Some things I could implement for now - I could fix audience, I could finish BR::Geo.
• I just realized that audience is really like CMU's radar.
• audience should simply summarize the incoming communications, for instance, 15 mail messages, 10 action items, 5 bugs reports, all resolved, etc.
• Some features audience needs, before I forget: should model who knows what, and more specifically, who knows which agents are programs. Also, if there is no danger in admitting to being an agent, the agent should then work with the user to determine what are the weaknesses in the agents dialog. This feedback should be sent to developers, or architect.
• audience will remember what was told to different people and wipe out redundancy, for instance, in group communications - it can use memory models however to determine whether to be redundant. These models can also use empirical data of the persons memory - as inferred or tested.
• audience needs to have a verber module for contacting people with respect to verifying agreement on various things.
• audience should count the individual items of information that the user and their contacts are disclosing.
• Should have redirects, like pse, tell audience, search goals
• Use Tabari in audience to classify communications.
• We can use this to code relations through audience. In reality, audience should be monitoring communications, using RSR or dialog or whatever.
• Great - Tabari and other coding software provides the data for a great taxonomy of action types (may do hierarchial classification already) for use with audience/diplomat
• Job search ought to interview the user, perhaps using an improved templated dialog system from audience, to extract the user's skills. (You see I'm really forgetting the proper role of each of these systems.
• Machiavelli/audience needs to consider this: http://library.n0i.net/advocacy/ba-dladv/
• Keeping exact track of what people have said will be an important feature of audience.
• If I ever need to - here is a great survival plan. RSR, verber, audience, etc must be functioning. Bury all my important belongings except for necessities - as planned by verber. Then, having maybe one system hopefully a laptop, leave town with enough money and possibly a bike, and move to an area where there should be lots of low paying jobs (walmart, etc.)
• audience should take into account the maximum send length in AIM.
• RSR can be used to train OTHER people, through audience.
• Note that CELT could be used for audience/Machiavelli/pse, for audience for ACLs, for Machiavelli for who should know what, and for pse for plan information and proof - mixed with CPR (core plan representation) and those kinds of things at teknowledge
• With audience - on IM it should model normal users behaviour - for instance it should not simply respond to everyone. I don't do that.
• audience should function similar to SaddamHusseinOS, which tests people to determine reliability.
• adzapper and dansguardian should be part of audience.
• audience: OurNet-FuzzyIndex-1.60
• audience should install the proxy which blocks the user from accessing certain sites - and a list should be maintained - along with the reason for blocking it.
• A devious little trick is that we can create different fake personalities using Machiavelli/audience, and use these to influence targets.
• Just get a basic chatbot working for audience, instead of worrying about how good the chatbot is. We can always find-or-create a better one.
• I need to finish audience so stupid communication slip up's cease.
• aer380-40.pdf for audience
• audience should definitely incorporate the concepts from this site in general : http://www.useit.com/alertbox/20030630.html
• audience should use ConceptNet's ability to judge the gyst and the emotion of a letter to classify angry letters. We should see how that works after setting up the XMLRPC server.
• We can use audience to enage people tha that we are on reasonable terms with to find out what they are up to, and which of their major goals have completed, what their new goals are , etc.
• audience would benefit from the Dialog engine project.
• For audience http://www.etc.cmu.edu/projects/DialogEngine/index.html - in order to automate my "character".
• If I'm clever I can fight so that I only have to work on certain days. Specifically start a new system that plays out the work game this way, and fights for me. Politicing, warring, so that I may work on my projects more. This is really audience.
• Write system "attack", submodule of audience, which fights back!
• audience: http://freshmeat.net/projects/pkt/?branch_id=50215&release_id=186636
• One interesting thing that audience should do is monitor the state of communication.
• Right now document modelling is done very little at all. There is a lot of guess work about what your audience knows.
• In this way, way point routes can be had. I wish we had a waypoint DB of CMU's campus. I suppose that would not be too hard to generate. It would be nice to have connectivity information gleaned in this way. The most important point of all of this is prevent me from making the mistake of say going to the undergraduate lounge. Permission for any movement is to be had. Also, permission for any social interaction is to be had. Machiavelli, I suppose, must ultimately represent this list, not audience. Agentifying everything has the negative affect of forcing a certain design philosophy on all software, and a bad one at that since unilang is so primitive conceptually.
• cookiebox should be used with audience for privacy - should stress privacy for audience! http://freshmeat.net/releases/183312/
• Need to come up with a set of sentences which we might ask people to determine their interest level. This is a pretty useful idea actually, have audience administer adaptive quizzes to people since my conversations are not all that deep.
• I need to implement that stuff where - when I am continuously editting buffers within certain dirs it records this as time spent on the project. Besides its obvious that there will be too much stress until I implement the audience stuff system. On the otherhand, how I can I work if I haven't eaten. The solution therefore, is to run, to increase my endurance and my ability to work. This system, BTW, can be applied to also monitor recreational reading.
• (Definitely we are going to need to do the following. Before meeting my parents I am going to have to finish the MKS, and this will include a bidirectional speech interface that interfaces to audience and uses dialog management in order to do these things.)