Skip to content
This repository has been archived by the owner on Apr 29, 2020. It is now read-only.

List of other specs to read #3

Open
jbenet opened this issue Nov 24, 2015 · 11 comments
Open

List of other specs to read #3

jbenet opened this issue Nov 24, 2015 · 11 comments

Comments

@jbenet jbenet mentioned this issue Nov 24, 2015
6 tasks
@rektide
Copy link

rektide commented Nov 24, 2015

@shazow
Copy link

shazow commented Nov 24, 2015

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
Copy link

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

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

@jbenet
Copy link
Contributor Author

jbenet commented Nov 25, 2015

Thanks! updated. Moar :)

@bnvk
Copy link

bnvk commented Dec 1, 2015

The decentralized social protocols I follow the most are:

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

@jbenet
Copy link
Contributor Author

jbenet commented Dec 2, 2015

@bnvk we're storing at rest data as IPLD

@harlantwood
Copy link

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

@nginnever
Copy link

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://github.com/soundcloud/roshi

Maybe off topic from POST.

@haadcode
Copy link

@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://github.com/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://github.com/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
Copy link
Contributor Author

jbenet commented Jan 19, 2016

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 notifications@github.com wrote:

@nginnever https://github.com/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://github.com/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://github.com/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://github.com/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
Copy link

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants