happybeing: happybeing: Is it a way to implement pubsub,

dirvine: dirvine: This is more general purpose, but the impl will make the message type generic allowing any type of message/event to be passed around.

I was also wondering and interested in understanding if this could be the foundations to have a publish/subscribe mechanism in safenet, perhaps a non-persistent one, i.e. not stored on the vaults/chunk store, with some TTL included.

Perhaps I’m getting this veeeery wrong, but based on your comment David, I was thinking if we could use this gossip protocol to allow an app to send a request which is transformed to a particular type of event (in the gossip protocol) within the targeted node’s group.

I know this might not make any sense, but here I go anyway, e.g.:

1- My “live weather” app publishes a MD (let’s call it the ‘weather events MD’) with a specific type tag that triggers the “creation” of a gossip event type.

Different topics for the same gossip event type could be defined by the app in the MD as entries, let’s say my app puts two topics by having two entries (this would be specific to the app’s protocol spec. just so subscribers know which type of topics they can subscribe to, again, purely application specific):

[ "temperature" => <MD 'A' xorname which contains up to date info about temperature>, "humidity" => <MD 'B' xorname which contains up to date info about humidity> ]

2- Then another app can send a “subscribe” request to the ‘weather events MD’ address (specifying the topic/s of interest), therefore nodes in the targeted group could maintain the subscriber’s connection end in a in-memory table (I’m not fully sure about the challenge/restrictions for having a connection end to send a message to a client app), which would be accomplished by just sending an “update subscriptions table” gossip event internally within the group.

3- When my “live weather” app updates the current temperature in MD ‘A’ because it sensed a change in current temperature, it then sends a “notify” request to the ‘weather events MD’ group, which causes the targeted group to check the in-memory subscriptions table and sending a notification message to each subscriber/client app (they can correlate the topics each subscribed to with the topic defined in the notification request).

It seems to me that if all this makes sense, the toughest part could probably be preventing it from spammers, but perhaps this could be handled in a analogous way as of persistent storage, having a different persona that can farm only these non-persistent events in memory, earning some safecoins by keeping the subscriptions table in memory, and having the apps to also pay for this subscriptions and notifications messages,…and we would be already enabling farming on mobiles !? what???