List of other specs to read

[jbenet]

Let's keep this list updated:

• Matrix: https://matrix.org/docs/spec/
• WebDAV: http://www.webdav.org/specs/
• XMPP: https://www.ietf.org/rfc/rfc3920.txt
• https://activestrea.ms
• Schema.org: https://schema.org/BlogPosting
• Nightweb: https://sekao.net/nightweb/protocol.html
• tent.io: https://tent.io/docs/posts
• IRC: https://tools.ietf.org/html/rfc2812 https://tools.ietf.org/html/rfc2813
• Open Peer: http://openpeer.org/ http://docs.openpeer.org/OpenPeerProtocolSpecificationAnnexRolodex/
• Pond: https://pond.imperialviolet.org/

Come on, let's get like 30 more.

[rektide]

https://schema.org/BlogPosting
https://sekao.net/nightweb/protocol.html

[shazow]

IRC: https://tools.ietf.org/html/rfc2812 https://tools.ietf.org/html/rfc2813

At the very least, lots of lessons to be learned of what not to do. (Modes is possibly my least favourite part of the spec.)

Also might be interesting to compare to where IRCv3 is headed and what use cases they're prioritizing: http://ircv3.net/

[mekarpeles]

http://openpeer.org/ is aligned with the notion of a POST "Chat" Ext or "Social Network"

See spec: http://docs.openpeer.org/OpenPeerProtocolSpecificationAnnexRolodex/

[jbenet]

Thanks! updated. Moar :)

[bnvk]

The decentralized social protocols I follow the most are:

• Webmention - https://indiewebcamp.com/webmention
• Microformats2 - http://microformats.org/wiki/microformats2
• Pump - http://pump.io
• Buddycloud - http://buddycloud.com/developers

And for the lulz, curious what you think about storing at rest data in unix mbox format 😝

[jbenet]

@bnvk we're storing at rest data as IPLD

[harlantwood]

A nice collection of protocols: http://lov.okfn.org/dataset/lov/

[nginnever]

http://kafka.apache.org/ - Kafka is a distributed, partitioned, replicated commit log service. It provides the functionality of a messaging system. Cluster based

And apparently soundcloud did some work here too
https:/soundcloud/roshi

Maybe off topic from POST.

[haadcode]

@nginnever

While message brokers (kafka) and event stores (Roshi) are not strictly related to POST (rather CRDTs, see ipfs/notes#40), I'm working on something that essentially works as an event store/commit log/whathavewe. If this gets too offtopic for POST, let's move the discussion to somewhere more approriate.

It's not quite ready yet, but I hope to be able to put everything on Github later this week. You can take a look at https:/haadcode/orbit-client for a preview. I just added remove() today and I have an idea how to expand the implementation to a KV-store using same mechanisms, so hopefully can implement that this week. All data is stored in IPFS, but it uses a server atm. Eventually it'll be able to work as fully decentralized system, perhaps even fully distributed. I believe (at least some) CRDTs can be implement in it, too. This, however, requires couple of features in IPFS to be implemented, mainly pubsub. My goal is that orbit-client will provide a transition path from a client-server architecture to decentralized one over time as the required features are available in IPFS. What I see atm, though, is that this could very well be a good starting point for a event store/message broker/kv-store on IPFS.

It's based on Orbit (https:/haadcode/anonymous-networks/) and my goal is to make Orbit use the orbit-client in the near future.

If you (or anyone else) have comments, ideas or questions I'd be happy to get your feedback. Once there's a working version, contributions would be highly appreciated! I expect there to be a good starting point for more work sometime in Feb.

[jbenet]

im sorry i dont have time to work on POST this month.

but please help me merge IPLD. there's important questions to resolve there
that need to be done before we can make POST happen.

In fact, would be useful if someone wants to take a stab at a rudimentary
POST on top of the current IPLD with the basic fields @mekarpeles and I
thought up a while back. What i mean is just make the JSON (or YML)
representations of the POST items (messages, linking to each other) in IPLD
syntax, so that we get a sense of what IPLD doesnt have right

On Monday, January 18, 2016, haadcode [email protected] wrote:

@nginnever https:/nginnever

While message brokers (kafka) and event stores (Roshi) are not strictly
related to POST (rather CRDTs, see ipfs/notes#40
ipfs/notes#40), I'm working on something that
essentially works as an event store/commit log/whathavewe. If this gets too
offtopic for POST, let's move the discussion to somewhere more approriate.

It's not quite ready yet, but I hope to be able to put everything on
Github later this week. You can take a look at
https:/haadcode/orbit-client for a preview. I just added
remove() today and I have an idea how to expand the implementation to a
KV-store using same mechanisms, so hopefully can implement that this week.
All data is stored in IPFS, but it uses a server atm. Eventually it'll be
able to work as fully decentralized system, perhaps even fully distributed.
I believe (at least some) CRDTs can be implement in it, too. This, however,
requires couple of features on IPFS to be implemented, mainly pubsub. My
goal is that the client lib will provide a transition path from a
client-server architecture to decentralized one over time as the required
features are available in IPFS. What I see atm, though, is that this could
very well be a good starting point for a event store/message
broker/kv-store on IPFS.

It's based on what Orbit (https:/haadcode/anonymous-networks/)
uses and my goal is to make Orbit use the orbit-client in the near future.

If you (or anyone else, @jbenet https:/jbenet I'd be
curious to hear your thoughts on this) have comments, ideas or questions
I'd be happy to get your feedback. Once there's a working version,
contributions would be highly appreciated! I expect there to be a good
starting point for more work sometime in Feb.

—
Reply to this email directly or view it on GitHub
#3 (comment).

[haadcode]

@nginnever Take a look at https:/haadcode/orbit-client now and see if you have any comments or ideas. Contributions would be hugely appreciated, too!