Fautore Interfacing

Applying the Fautore Operational Principles in the myriad of today's technological offerings can be a bit of a sticky wicket. There needs to be a balance in providing structure without being so restrictive nothing can get done.

The below table lists out specific application interfacng considerations, how they fit into the Fautore paradigm and a bit of rationale behind the the decisions made... if the decision has actually been made.

Table Headings

Application
Potential third party software recipients of Fautore manageed data being listed as an example. This software is listed as an example only. Being listed is in no way an indication of being able to actually send data to the application.
Interface
An indication as to how information can be passed to the application via fautore.
    • FtF - Fautore-To-Fautore communication. Indicates that communication can only happen via the standard encrypted inter-tribal interface. No API communications are allowed. Independent Fautore installations must be used by both the sender and the receiver.
    • API - Application Programmatic Interface. Indicates that the application can make calls directly to the internals of Fautore to create a much tighter coupling by which data can be transferred directly. Applications communicating with Fautore in this way should be considered highly trusted members of the tribe and must reside within the POD (FOD).
Status
The status of the decision for how the application should interact with Fautore to pass data. This is not the status of the API for the API development between Fautore and the application.
    • D - Decided, a decision made; there is no longer an open discussion on the topic.
    • U - Undecided, there is a sense of direction, but also grey areas of potential conflict in the Fautore Operational Principles that still leave discussion open for how the situation should be handled.
Rationale
An short explanation of the reasoning behind the decision listed in the "Status" column.


Table of Examples

A table of application examples and how Fautore would be expected to pass data to them. An important assumption made in the table is that line items listed with an interface of API are installed within the POD. It is possible for the listed applications to be installed outside the FOD, in which case they would require an FTF interface.

Application Interface Status Rationale
Tiki
API
D
Tiki is a CMS (well, more than that actually) installed within the FOD
Synology
API
D
Synology is a "data center in a box" installed within an FOD
facebook
FTF
D
facebook is a third party service application installed outside the FOD and must therefore communicate via the FTF strategy; no matter how unlikely it is the company would install a Fautore front end.
Twitter
FTF
D
Twitter is a third party application installed outside the FOD and must therefore communicate via the FTF strategy; no matter how unlikely it is the company would install a Fautore front end.
SMS
API
U
SMS is not a technology installed in FOD, it is however a direct person to person communication across established infrastructure managed by companies with a vested interested in the security of the message. SMS content is not persistently stored.