Online Comunication Engine

The Online Communcation Engine (OCE) is the workhorse of the Online Social Advocate (OSA) standards set that performs all communications routing tasks. The below diagram illustrates the construct of the OCE and provides an idea for its function. See the OSA Overview page for a representation for how the OCE fits within the overall OSA standards suite.

Operation

The OCE itself communicates only with other OCE's and locally registered applications. Registered applications must reside within the defined Personal Operations Domain ( POD ) to be registered with an OCE.

Theory

The objective of the OCE, and OSA in general is to establish a viable trust relationship between Internet participants. This objective is a compromise departure from the impossible goal of 100% secure communications. The communications between OCE's are encrypted for a secure data transfer, however the security of the end-to-end communication is subject to the reliability of the endpoints. As in real life, the transfer can be made to have a near guarantee of being secure, however the security of the information with the recipient is a matter of faith in that recipeint, ergo - trust.
A real life parallel to this concept is that a message can be put into a locked briefcase and given to a courier with reasonable expectation it will arrive as intended and unmolested. Once the briefcase contents are read by the recipient however; the security of that information is, as always, subject to the trustworthiness of the recipient to safeguard the information. The role of the OCE then is to be that secure courier that communincates in the agreed protocol of OSA to deliver information only to recipients trusted to safeguard information to the degree intended by the sender.

Operational Concepts

An OCE operates as the boundries of a community, sometimes referred to as a "Tribe." A "Tribe" refers to a complete collection of account holding members, instructions and applications. An OCE is a single monolithic container of functionality. All components, in the way of members, applications and instructions, belong to one tribe. All data keys are unique to the one OCE. The components of an OCE can be grouped into logical constructs called "Coteries." Local OCE members are provided ownership of individual Coteries as workspaces to define their own OCE operational parameters. The associated POD of an OCE defines the trust boundries within which the components of a tribe operates. Information can pass freely within the POD, passing information outside the POD has tighter controls.

OCE primary function is to manage trust relationships and route information within those relationships accordingly. Actual operational features of OCE's may differ from one to the next, as long as the OSA trust and routing message integrity remains in tact. An OCE may for example introduce the concept of "Member Groups" to ease message routing to multiple members. While a Coterie is a functional grouping characteristic that is part of the OSA OCE standard to provide individual workspaces, internal data management features like member groups are OCE specific in their availability and function. Other features such as time delay message deletion, plugins to manipulate data in transit and auto responses are examples of other features one might find in one OCE, but not another.

OCE Rules

The below rules must be followed by any OCE to be considered OSA compliant.

1. OCE Communications outside the POD must be only from one OCE to another OSA compliant OCE.
2. OCE communication within the POD must be only to registered applications
3. All OCE communication to, from, within or external to the POD, must be by OSA USDP using the OSA USDS.
4. Any message not having a "Visibility" value must be treated as a value of "1".
5. An OCE cannot override an incoming message "Visibility" setting to be lower than the message setting without manual intervention.
6. The "AppKey" is never sent outside the POD.
7. The App defined in "AppId" is the default recipient if no other applicable rules are defined.

Application Rules

The below rules must be followed for any application to be consider an OSA compliant application.

1. The application must report all OSA compliance data accurately at all times
2. The "Visibility" value communicated at registration must be accurate for the application as describe in the OSA visibility rating chart.
3. The application must respect USDS visibility ratings of messages in transit
4. The application must reside on a device within the POD
5. The application must never communicate directly with another POD/OCE
6. The application default functionality must only communicate with the local OCE via the OSA USDP using the OSA USDS
7. Any functionality causing the application to communicate information outside the POD must be obvious and treated as an "opt-in" with reasonable steps taken to ensure a party of average technical expertise responsible for approving application registration is aware of exactly what data is communicated outward, to what destination and when.
8. Every direct recipient of information forwarded by the application must be known by, and explicitly agreed to, by the sender of the information or manager of the OCE.
9. Applications are registered at the master OCE level
10. Application access through instructions can be controlled at either the master OCE or Coterie level

Message Handling

An OCE can be structured any way that makes sense to the developers. Messages can be processed in one uninterrupted flow from beginning to end and discarded upon failure, or they can carefully managed in many tightly verified steps to ensure exacting handling. The requirement is in following operational standards to achieve expected outcomes. How the outcomes are arrived at within standards is an OCE specific set of decisions left up to the developers in respect to the needs they are working to satisfy.
For the purposes of illustrating the expected outcomes of instruction processing we are breaking the message flow through the OCE into two categories of "Intake" and "Transmission."

Intake

During message intake, our example OCE accepts a message, examines it's component parts and stores individual intended recipients to a queue called "ActQueue". This example assumes all security checks, decryption and authorization checks have been completed.

Processing instruction into ActQueue
-> Cannot specify dest app in USDS
-> Inbound from external OCE - no group processing
-> Coterie destination processing is OCE specific

if commons specified
    make "commons" actqueue entry (maybe even process)
    end processing this instruction
fi

if remote OCE specified
    if hash keys
        Process 'Local' value if present
        loop values straight to ActQueue
        end processing this instruction 
    elsif csv
        Process 'Local' value if present
        loop remote OCE keys straight to ActQueue
        fully process local reference
        end processing this instruction
    else
        straight transfer of USDS/Dest values to actqueue recipient
    fi
elsif local tribe
    if member(s) listed
        loop on member csv or process single
            if parity coterie membership with sender
                create actqueue record for member
            fi
        eloop
    fi
fi

if Dest->Coterie specified and Dest->OCE is local
    check to ensure sender is member or owner of coterie
    if hash keys
        loop on coteries
            loop on group arrays
                create actqueue entry for each group member
                    just the uid for the member
                    member will be processed for best recipient app in SendQueue
            eloop
        eloop
    elsif csv list
        loop on listed coteries
            create actqueue entry for each Coterie member
                just the uid for the member
                member will be processed for best recipient app in SendQueue
        eloop
    elsif single coterie
        if Dest->Group and from local
            if group csv list
                loop on groups
                    create actqueue entry for each group member
                        just the uid for the member
                        member will be processed for best recipient app in SendQueue
                    continue processing instruction
                eloop
            elsif single group
                create actqueue entry for each group member
                    just the uid for the member
                    member will be processed for best recipient app in SendQueue
                continue processing instruction
            fi
        else
            loop on listed coteries
                if sender has "broadcast"
                    loop on all Coterie members
                        create actqueue entry for each group member
                    eloop
                else
                    send to coterie chief only
                fi
            eloop
        fi
    fi
elsif Dest->Coterie set and Dest->OCE not local
    transfer Dest->Coterie value to ActQueue
fi

if group specified
    Not directly processed. Referenced from Coterie only.
fi

if member found
    not directly processed. Referenced from OCE section only.
fi

Transmission

In the transmission of the message data is pulled from our example ActQueue table storing a list of recipient actions and the database table(s) storing the actual message content. This example illustrates only the basic message build considerations and not the complete send process to include encryption, attachment of transmission headers and actual send.

Build message and send it

Extract recipient from ActQueue
Extract associated message data from DB
Build message
    set msgType to 'qMsg'
    if no msgKey value
        generate unique key
        set msgKey
    fi
    if no Visibility value
        set Visibility = '1'
    fi
    set Summary as defined by sender
    set Detail as defined by sender
    set Source->OCE to {local OCE}
    set Source->AppId as defined by originator
    set Source->Member as defined by originator
    unset Source->AppKey
    if Commons provided
        set Commons as provided by sender
        end Dest section build
    fi
    set Dest->OCE as defined in ActQueue
        or to {local OCE}
        or leave blank to default to local
    set Dest->Coterie as defined in ActQueue
    if Dest->Coterie defined
        set Dest->Group as defined in ActQueue
    fi
    set Dest->Member as defined in ActQeue
    set Object data as defined by sender
    set Adjunct data as defined by sender
Send message

Extended MIME

The below table explains the extended MIME types used in the Adjunct::Type field