I love using any PeerPouch instance as the "hub" since it makes a great default that's super simple to get into.
However there's a couple issues with this too. CouchDB isn't "supposed to" be used for realtime messaging, e.g. the signaling does leave permanent cruft behind in the database even after compaction. (Not to mention the current way of advertising shares leaves a lot to be desired…especially with regards to cleanup on navigation away.)
For example, with sendfile I had been planning that I would need to implement a ± full-fledged in-memory Pouch adapter for the server side just to avoid needless+slow I/O burden on my instance and involve arbitrary "garbage collection"–type requirements. With an option to use a custom signalling implementation, its serverside could become way simpler!
I've been thinking that a combo of global broadcast (e.g. request all shares to advertise themselves) plus targeted messages (for connection setup) would be a better model than share documents anyway. [I'm not terribly worried about scalability nor do I want to duplicate a proper full-on Bonjour/DHT/etc discovery protocol in this context…]
The default Pouch "hub" implementation of this would be pretty similar to the current to/from signal documents (probably with an added convention of self-deleting broadcast messages). Will have to think about where to draw the line though: does the custom backend simply shuttle messages, or is it responsible for maintaining the peer list as well? [probably the latter, since if someone is customizing the one they're probably customizing the other!]
This is somewhat related to #6, but could be done before/after as well.
I love using any PeerPouch instance as the "hub" since it makes a great default that's super simple to get into.
However there's a couple issues with this too. CouchDB isn't "supposed to" be used for realtime messaging, e.g. the signaling does leave permanent cruft behind in the database even after compaction. (Not to mention the current way of advertising shares leaves a lot to be desired…especially with regards to cleanup on navigation away.)
For example, with sendfile I had been planning that I would need to implement a ± full-fledged in-memory Pouch adapter for the server side just to avoid needless+slow I/O burden on my instance and involve arbitrary "garbage collection"–type requirements. With an option to use a custom signalling implementation, its serverside could become way simpler!
I've been thinking that a combo of global broadcast (e.g. request all shares to advertise themselves) plus targeted messages (for connection setup) would be a better model than share documents anyway. [I'm not terribly worried about scalability nor do I want to duplicate a proper full-on Bonjour/DHT/etc discovery protocol in this context…]
The default Pouch "hub" implementation of this would be pretty similar to the current to/from signal documents (probably with an added convention of self-deleting broadcast messages). Will have to think about where to draw the line though: does the custom backend simply shuttle messages, or is it responsible for maintaining the peer list as well? [probably the latter, since if someone is customizing the one they're probably customizing the other!]
This is somewhat related to #6, but could be done before/after as well.