ipfs-inactive / POST

[ARCHIVED] POST - a datastructure for human communication
24 stars 6 forks source link

List of other specs to read #3

Open jbenet opened 8 years ago

jbenet commented 8 years ago

Let's keep this list updated:

Come on, let's get like 30 more.

rektide commented 8 years ago

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

shazow commented 8 years ago

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 commented 8 years ago

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

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

jbenet commented 8 years ago

Thanks! updated. Moar :)

bnvk commented 8 years ago

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 :stuck_out_tongue_closed_eyes:

jbenet commented 8 years ago

@bnvk we're storing at rest data as IPLD

harlantwood commented 8 years ago

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

nginnever commented 8 years ago

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 commented 8 years ago

@nginnever

While message brokers (kafka) and event stores (Roshi) are not strictly related to POST (rather CRDTs, see https://github.com/ipfs/notes/issues/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 commented 8 years ago

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 https://github.com/ipfs/notes/issues/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 https://github.com/ipfs/POST/issues/3#issuecomment-172498207.

haadcode commented 8 years ago

@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!