FRDCSA | internal codebases | Audience

[Project image]

Architecture Diagram: GIF

Jump to: Project Description | Parent 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.

audience indirectly implements a system to communicate anonymously for people who are in need of maintaining contact but screening communications. This functions not only over the network, but also for other communication media, such as person to person. A temporary system of ACLs giving permission to participate in certain events is used. In the future, permission will be inferred from a KB through Machiavelli.

Network technologies involved are a web based chat server, freenet, and a freenet chat and mail system from http://eof.sourceforge.net/, as well as a screen for derogatory/hate/negative communications, and an interface to the unilang system.

This IM client is now operational and integrated with unilang. We still are adding features to this client rather than just starting it running now.

Currently, audience uses a custom system called Diplomat to guide behaviour intelligently. Diplomat uses Tabari to code audience communications into event categories. Then an appropriate response is generated. For instance, if the user is insulted, this event is coded (and logged to the event-system). Diplomat then employs planning wrt goals and social rules to determine an appropriate response, currently only using a simple state transition table, whereas in the future we might use AI adversarial planning tools. An appropriate response is selected and generated, and in this example, that would be to demand an apology. If this failed, relations would be reduced and if that failed diplomatic relations would be ended. Diplomat may probably end up as either its own system or in Machiavelli rather than audience.

Here is a sample of event types taken from Tabari: Accuse, agree future act, agree, apologize, approve, arrest person, ask information, ask material aid, ask policy aid, assure, break dipl relat, call for, cancel event, comment, consult, criticize, cut aid, cut routine act, decline comment, demand, demonstrate, denigrate, deny accusation, deny action, deny, discard, endorse, expel group, expel personnel, expel, explain position, extend econ aid, extend mil aid, force, formal protest, give other assist, grant asylum, grant privilege, grant, halt negotiation, make agreement, make complaint, meet, mil engagement, military demo, neutral comment, noninjury destr, nonmil demo, nonmil destr, nonmil threat, offer proposal, optimist comment, pessimist comment, plead, praise, prom material support, prom other support, prom policy support, promise, propose, protest, receive, reduce relations, refuse, reject, release, request, retract, retreat, reward, seize possession, seize, specif threat, state invitation, surrender, threaten, truce, turn down, ultimatum, unspecif threat, urge, visit, warn, and yield.

Another aspect of audience will be an intelligent communication proxy, that will actually communicate with the user to give them the impression of conversation. Language models will be produced from my writings and chat logs to interact with a yet to be determined authenticated chat bot/dialog system (most likely a hybrid unilang agent).

Note that, far from being a deceptive device, this agent will allow phenomenal improvements in socialization. For instance, people equipped with myfrdcsa can let their agents interact autonomously with other people's agents, and their agents can engage in a complex dialog respecting both users interests and privacy. In this way, one would not have to constantly go through the mundane process of becoming aquainted with other people and their BDIs. Rather, the most important concepts would be forwarded.

Also, their agents can autonomously "spider" the social network by asking for referrals and references by other agents. This will in effect unite the myfrdcsa together in a collective format that will result in immense improvements in capabilities. Furthermore, with trust-based knowledge sharing clients, combined with Clairvoyance for instance, users will rapidly become experts in all fields they are interested in. This is the mutual power goal that we are interested in. We are interested in maximizing everyone's capabilities rather than capitalizing on people's weaknesses for personal gain.

Last but not least, it should be a proxy for communications to the outside world, for instance, for Brainstorm - so that source identity is not revealed to parties who may reveal it to aggressors.


  • Develop a system part of audience and erc specifically for saving, organizing and searching transcripts of irc sessions
  • Implement audience module in free life planner for connecting to our mail servers and querying whether there are messages presumably sent to us by friends which have not been addressed. The system should simply indicate who has contacted us and how many messages are queued and what their estimated importance is.
  • Have audience check our mail and process with NLU for potential action items.
  • Create a keybinding for audience that jumps to a paper, which is globally bound so we can start cycling through. Or maybe make it load a list of all papers.
  • audience should handle communication with other FRDCSAs.
  • Set up audience-erc to send me messages via unilang when dmiles or jbalint surface.
  • find-or-create a function for erc /audience, like 'Ctrl-c Ctrl-spc', but which brings up the buffer containing the last received / (and or read) piece of text, and then the one before that, etc.
  • Write stuff for audience to be able to analyze email and act on it.
  • Use NLU to process our Email through audience.
  • Get audience working better.
  • Use audience to map out online email accounts and download copies of them.
  • Convert audience ball-in-court to a gui program that allows us to mark threads as read. And this way, stay on top of all of my important messages across all accounts.
  • Package audience IRC reader for auto-install.
  • Adopt audience ball in court in order to scan through spam for persons we should have paid attention to.
  • Send emails that are in the audience letter drafting stage...
    ("pse-has-property" "106505" "habitual")
  • Write a command to show me what to what are the most recently composed audience las letters, etc.
  • Have audience speech agent read back commands to ensure correctness.
  • Add something to the audience irc system to read :) as smiley, etc.
  • 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.
  • There have got to be tons of really cool people who want to get together and collaborate like Justin, Mike and I, therefore we need audience to be able to scale to that many people. We should eventually convert audience to use MySQL.
  • audience should not just have email support, but also conversation planning support. Could work multiparty.
  • 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.
  • 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.
  • /var/lib/myfrdcsa/codebases/internal/unilang/start audience broker clear corpus cso ELog OpenCyc pse unilang-Client
  • do phone soliciting of money using audience when it is working better. Hello, I am the personal A.I. secretary of the humanitarian inventory Andrew Dougherty. do you have a moment to chat? Good, well, Andrew Dougherty has been working for 6 years to develop a free artificial intelligence to aid the public good and to solve problems affecting people. He is not motivated by greed but by his values which instruct him to help other people. He is wondering whether you might be interested in reading more about his work to solve problems affecting people.... (this is terrible but you get the idea.)
  • 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.
  • 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.
  • 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.
  • reasonbase can use existing IM logs to find plenty of examples of arguments, and build an audience dialog system based on that.
  • audience should store its information in a researcher page in machiavelli
  • Obviously encryption falls under the responsibility of audience.
  • 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.
  • audience can use my extensive personal writings to compose arguments.
  • audience was already a good system, and now its even better.
  • audience should work to expose fallacies, in coordination with the Legal reasoning system.
  • It just occurred to me that audience out to be able to generate Conversation maps.
  • audience needs to interface with verber, and specifically, do conformant planning over communication acts.
  • audience should correct for common name substitutions, prompting in severe cases.
  • audience will be necessary for job-search, and even manager if I recall correctly.
  • Some of the features for audience that have emerged, first, you can have a phone interface that will call people.
  • Possibly use celt as a system for keeping track of things over audience.
  • Deregister audience
  • audience should speak its own format, and thus be able to communicate with itself.
  • Some things to keep in mind - if someone has no permissions to talk with audience, should we block them or just ignore them?
  • audience should support file transfers and voice.
  • We can mine other people's logs to get an idea for what is appropriate, audience can recommend to us what is appropriate.
  • I have to email this one kid some chess info, but only feature not yet implemented for audience is sending mail.
  • 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.
  • 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.
  • I can see now long chain events like Something happening -> verber -> event-log -> audience -> machiavelli -> audience -> (internet) -> etc.etc.etc.
  • 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.
  • 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.
  • audience will provide a framework in which to test empirically various communication strategies.
  • Using audience of course.
  • I can use audience to log when people have logged in or out.
  • Fix the problem with audience screwing up on anything but a commnad
  • 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.
  • Note that currently audience is subject to switch receiver on you without noticing, and you could make many mistakes that way.
  • Fix audience bug where it logs off but doesn't think it has.
  • In the future audience should automatically tag threads using TDT.
  • I mean sometimes audience might not need to verify receipt, but it should for important matters.
  • 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.
  • Can use machiavelli in combination with audience and various requests to estimate social network.
  • Should simply implement the remaining audience functionality in order to have control over interns.
  • audience should store its information in a researcher page in machiavelli
  • Could use spark as my task model and use it more than just for say, audience.
  • reasonbase can use existing IM logs to find plenty of examples of arguments, and build an audience dialog system based on that.
  • /var/lib/myfrdcsa/codebases/internal/unilang/start audience broker clear corpus cso ELog OpenCyc pse unilang-Client
  • 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.
  • Write subsystem of audience (or maybe fieldgoal or boss) to catch up with other developers
  • Obviously spark is useful for audience, and many other things.
  • Develop talking points system (within audience)
  • Use an event system and formally model requests through audience.
  • audience should possess tact.
  • audience should make more use of the letter authoring system.
  • Should act as a scratchpad for audience.
  • /var/lib/myfrdcsa/codebases/internal/unilang/start audience broker clear corpus cso ELog manager OpenCyc pse unilang-Client
  • audience should function together with dbmail and rmail, as a mail client.
  • audience should record which mail messages need to be responded to.
  • audience should use dbmail as the backend for mail storage.
  • In fact antispam console should simply be a filter for audience.
  • Read me things in the background through clear, like audience emails.
  • audience should integrate with LDAP.
  • For audience, create a bayesian filter for parsing mail.
  • audience should use LDAP for identification.
  • 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.
  • 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.
  • 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.
  • Should be able to start an agent from this window, have a unilang, start agent audience, type feature.
  • Based on estimated email message importance, if people do not acknowledge, audience should escalate to phone calls and such.
  • KBS, MySQL:freekbs:default assert ("belongs-to" "50959" "audience")
  • Fix audience LAS to use BBDB.
  • The audience system for tracking whehter people have gotten back should do so by a given date, i.e. if so and so has not responded by 2 days, alert me, and/or resend.
  • Write various audience modules for interactiing with different mail systems, like yahoo, and our system.
  • System for making sure we've gotten responses should also check whether we've responded to others. Part of audience after all.
  • Need to find a way to keep track of who I've written. This is audience.
  • Get a blog audience for my project.
  • We need a system for recording who I've sent email to and what the state of the various correspondences is. audience.
  • Develop extension to audience that tracks which queries sent to people via email, etc, have been answered.
  • ERC stuff belongs in audience most precisely I guess.
  • 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.
    ("completed" "9355")
  • Use spark for audience
  • That functionality might go into audience come to think of it.
  • 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
    ("rejected" "3673")
  • 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.
  • Justin was exheedingly unhelpful. I can't wait to have the audience diplomatic software working. However, in this case, Justin is probably reacting to the situation more than anything else.
  • 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.
    ("rejected" "3294")
  • 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
  • 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.
  • Have a general purpose text retrieval novelty engine that interoperates with everything - papers, books, RSS feeds, chat, etc. In fact, audience need only interact from this point of view.
  • 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.
    ("completed" "303")
  • (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.)
  • We really have to avoid those things. To avoid these things, we need to be self contained. Therefore, in terms of the project, there is no contacting anyone about the project. Eventually audience and machiavelli will enforce this. Secondly, we need to set up complete food management. Waste is secondary. Third - movement discipline, if we ever get a speech engine workign.
  • bld-postfix audience?
  • Nitpick uses audience and machiavelli to assist in communication
  • Use audience to block Jana's IMs on days I am working.
  • The role of audience is very much related to the expertise modelling.
  • Make sure that project summaries are well done and targeted to the proper audience, therefore, have internal documents detailing more technical points but also important communicative descriptions on projects that are targeted towards readers of certain audiences. (Note that everyone says "work in progress"). Note that for predator we could mention that in addition to a semi-automated packaging system, it is a packaging system which aims to capture packaging knowledge from the user. And this is true, that we can augment our own knowledge by observing what the user is doing. We should use NPDDL for predator, among other things.
  • possibly use http://freshmeat.net/releases/170956/ as a grammar checker for audience
  • audience could use Skype, it even does audio communication.
  • audience needs: Briefing Associate An environment based on MS PowerPoint for authoring semantically grounded briefings. In addition to creating semantically grounded briefings, the BA exposes the briefing\x{2019}s semantic descriptions to external modules called analyzers, which will perform specialized services or analyses for the author. Such analyses might provide feedback to the author, extend or modify the briefing, or produce external documents derived from the descriptions.
  • Machiavelli should handle Hype calculations, with audience.
  • Use audience and radar to, instead of sending many emails to one person, find all the projects they are PI on and contact them about the release status.
  • Email Classification and Prioritization should be part of audience
  • So audience is coming along fine, I think we should add support to distinguish the humans talking, as well as add ratings, and allow import of conversation modes.
  • So I just realized that in some sense, audience/machiavelli is a CMS: content management system. That's what it does, although I suspect it gives more intelligence than is common with those systems. Of course it does.
  • When writing a letter to someone, audience should suggest items for inclusion based on what you were writing before.
  • Use Dabbish's radar information to determine illocutionary force applied to audience.
  • anon-proxy is useful for audience
  • audience monitor communication in different contexts and compare to see if a person is lyin gin a certain area
  • audience should use appropriate IRC channels to post questions
  • train audience using my AIM logs to be able to chat reliably.

This page is part of the FWeb package.
Last updated Sat Oct 26 16:50:36 EDT 2019 .