search

exodusproject / spec

(Discussion of) specification of the procotol.
3 stars 0 forks source link

Modules on top of the base protocol #1

Open Zatnosk opened 8 years ago

Zatnosk commented 8 years ago

arturovm said: "the base of the protocol is the peering mechanism, etc. and then on top of that, we add these modules. And we ship the reference implementation with a couple of modules ready to use". Example modules: Pubsub/social module: can do statuspost/tweets, or essays/blogs, or videos/youtubethings, etc File module: handles filesharing and backuping/syncing Maybe a forum-module? Forums are hacky if made on top of pubsub-architechture

peakwinter commented 8 years ago

Perhaps a semantic question but how do we want to think about "addons" or extensions in general? One of the things I liked most about Tent is that it relied upon a uniform method of data exchange, easily changeable for different "post types". Is this the kind of direction we want to go in, or are there good reasons for changing this idea?

Zatnosk commented 8 years ago

I think a problem with post types is that they're good at social (i.e. the pubsub model), but they're not necessarily good for filesystem backups, file sync or even file sharing. I'm not sure if that answers your question. We might have benefit from a cross-module "post-type" system.

arturovm commented 8 years ago

@peakwinter The way we were thinking about this, which I don't know if you read, is that we have a minimal base protocol, and then every single functionality is defined by modules. When I think of modules, I think of things like SMTP extensions, which add new capabilities to the servers/clients; stuff like new commands or the UTF-8 encoding.

These new capabilities added by modules (or extensions, in the case of SMTP) are announced at the time of the handshake, and then the other nodes know how to interact with this particular server, depending on the intersection of the capabilities of the two servers that are interacting.

What do you think?

arturovm commented 8 years ago

@peakwinter Oh, and another thing. The data format is still to be defined, but we have the concept of Resource, which represents everything in the server: posts, photos, documents, etc. I don't know if there will be a pre-defined data schema, but we should absolutely discuss this. Although this is in the data domain, and I think we should properly stabilize this first, and then move on to that to give it the attention it deserves.

arturovm commented 8 years ago

Ugh. I just realized that #3 is a duplicate discussion of this subject.

bnb commented 8 years ago

Please see contents in #3 before continuing!

Zatnosk commented 8 years ago

In my view, Modules have two parts: An (other) server-facing part and a client-facing part. Both parts of the Module would then define a set of primitives in their API, to allow efficient communation of relevant data.

Example: The* PubSub Module The server-facing API would allow other servers to register a "follow" which specifies what type of resource the entity (representing the end-user) is interested in. It would also allow receiving resources from other servers, that it is following. The client-facing API would allow clients (desktop, mobile and web apps) to fetch a feed of resources, suitably paginated. It would also allow clients to request the server to "follow" an entity (on the same server or a different; should be identical).

Such a Module would allow third parties to build Twitters, Facebooks, Instagrams, etc. It would be possible to use it in a calender to see some other entity's calendar by following their event-resources, but it would not support RSVP'ing to events or actively inviting entities. Such functionality should exist in a separate Event/Calendar Module.

*) I imagine that there should only be one standard Module for PubSub (aka social), one standard Module for Events, etc.