Adin Schmahmann

> Extend the signature of Publish() so it can take functional options to configure the reliability characteristics we want. Note this is already available in #184

TLDR: This the proposal does not fully solve this problem, but it's not clear it has to. If we want to more fully solve this problem there are more things...

@aarshkshah1992 fine by me, not sure if @raulk has any thoughts/concerns here.

@raulk I'm running into some problems with this in go-libp2p-pubsub-router which builds a persistent value store on top of pubsub. I'd like to solve the "messages can be dropped silently"...

I've been talking with @Stebalien about this a bit in the context of #184, which has necessitated that we take another look at the PubSub interfaces. There's a current proposal...

Thanks for the clarification @jacobheun. If this is about effectively having latency groupings/levels then this is definitely not in the implementation cards for IPFS 0.6, but allocating time for planning/investigation...

I disagree with this idea given the current way this library is set up. However, if we were prepared to make a couple changes I'd be all for it. 1)...

@yiannisbot AFAIK that paper's attack doesn't really apply to us at all. It's based on two assumptions: 1) PeerIDs are easy to generate/forge 2) There is a property of a...

> how would merge indicate two records couldn't be merged They can always be merged, but maybe there's a better word to use here. The question being asked of the...

> So let's address the data using this common identifier, and not a preimage of it. This will allow us get rid of monsters such as the [preimage table](https://github.com/libp2p/go-libp2p-kbucket/blob/b4e9fd39b8c68f7aea46e8d47c4cd036a9a70871/bucket_prefixmap.go). This...