Foil is a mailing list manager; it is also a social network based on email. Although email itself is a social network, Foil innovates on the (now forgotten) concept of mailing list.
We could say that this is a mail application, in contraposition to web applications. Nonetheless it is built over Rails, so it has a web front-end too.
Spaces store messages. They have both an URL and an email address, so messages can be posted through HTTP and SMTP, viewed on the web and relayed to email inboxes—therefore providing mailing list functionality.
Spaces have read and write Unix-like permissions involving owners, owners' contacts, all, and places in between.
For example, a personal email account is a space readable by its only member and writable by everybody; a blog is just the opposite, a public-readable and a private-writeable space. A wall and other types of environments can be achieved through combinations of permissions.
Organizations gather spaces. In fact, these provide the domain part of the spaces' URL, and the latter just the path.
They act as meta-members and have control over its spaces. I have not resolved much things about organizations, really.
Every member may have its personal space within an organization, which consequently grants an organizational personal email address. Note that this address is just an alias, much like any other generated by a space, that forwards messages to an external account (i.e. Gmail).
All the messages that cross the boundary of the organization typically should be kept. Incoming messages do not present any problem, since they are processed by Foil before reaching an external account. Outgoing messages need a mecanism to go through Foil in order to be recorded and also re-arranged to look like sent from the address of a space.
This could be achieved posting a message to the "sender space" including somewere in the body TO, CC and BCC addresses along with a password. Foil would remove these and send the email accordingly. For follow-ups this would not be necessary.
Spaces restricted to the group members are created for internal communication, possible following some organizational structure criteria. Structure templates, serving different kinds of organizations, could be available.
A common situation in a group is the necessity to operate one or more contact addresses in collaborative manner. Such spaces would distribute incoming messages between its members and would let to send messages in the same way as personal spaces. Outgoing messages would be also distributed.
SMTP does not authenticate sender's address. When necessary a password should travel within the message's body. Mails arriving from known providers' servers could be trusted.
Messages sent to inboxes will vary its content according to the recipient's preferences.
- Debate and voting tools
- Attachments, file sharing
- Circles, for enhanced privacy
- Sub-spaces, for forum behaviour
- IMAP