RFC: replace publish/add with push/pull

[b5]

First pass at a big overhaul to the way we move versions around.

[b5]

Ok we talked about this a bunch on our community call

Here are some of my notes from it.

• Rico: "the phrase publish let a user know that when they hit publish, it'll make things visible to the world"
• Asmir: coming to qri fresh, there's a lot of term confusion in general. I'd like to see things funneled down to fewer commands. Many people will want to use a happy path of one or two commands, and get away from
• Dustin: agree with Asmir. We have an opportunity to reduce the complication with git. Having fewer commands with better defaults is better. For example, can clone be a flag on another command?
• Rob: We need to show this to real users & get their feedback
• Chris: I agree with Rob's comments on the RFC about removing datasets. I'm confused about how to unpublish.
• Kasey: I'm also curious about how to push or pull specific versions?
• Brendan: you can pull specific versions with qri pull use/dataset@/ipfs/VersionHash. It'd also be nice to be able to reference a specific index from the log by number like "qri pull the 3rd commit"
• Dustin: what if we merged "clone" into "checkout"? We've struggled with weather or not to call out network / not network as a clear distinction. Does it matter that there's a network call?
• Rob: there should be a flag like --offline
• Brendan: We have to deal with another issue: pushing a number of versions that together exceed a storage cap. I'm proposing here pushing by default should accept newest versions, drop from oldest.
• Asmir: You're potentially opening a huge can of worms here. What if I want to be an archive node that prefers OLD versions? You're also biasing the network towards recency, making it probable that the network will forget original versions, making the whole audit trail at the beginning drop. This needs to be worked out as an RFC of it's own.
• Rob: this absolutely needs to be configurable. What if instead as a default for now: "if it doesn't fit, it doesn't go".
• Rusty: if you can know in advance of the push starting, you can present an error & give the user a chance to bail.

There's lots of great feedback here I'm going to work in directly.

[b5]

Look, reference section for this isn't written, but the rest of this is ready for review, incorporates many things the using qri call.

[ramfox]

V cool. I think this is definitely the right way to go.

There are two major things I think need to be discussed.

The first is the language and logic around what makes a dataset 'published' how we calculate that. Is the word/concept of 'published' being removed from our lexicon? Can datasets be considered 'published' or are only versions 'published'. How do we know or determine if a dataset is 'pushed' to more then one place? Do we need to keep track of it? Mostly thinking ahead to how we show/display this on the desktop and what information we will need to convey the correct state of a dataset.

The other major thing is 'unpublish'/remove from a remote, but I believe some of that is talked about in the storage rfc

[b5]

Thanks to @ramfox's feedback:

The first is the language and logic around what makes a dataset 'published' how we calculate that.

This is now covered in the "access" RFC.

The other major thing is 'unpublish'/remove from a remote

This is now covered in the "delete/drop" RFC.

[feep]

Links:

"access" RFC. "delete/drop" RFC.

[b5]

Ok, it's in! Thanks for everyone's input!