For JAMS to make its next big leap we will be in need of some important but currently not present features.
First off thank you for the streaming support, it will be put to use soon.
What JAMS and other modern web apps for SAFE (such as decorum I would guess) will desperately need is PUSH notifications on changes made to an MD.
Is this something in the pipeline for the near term?? I’m not sure pushing much further for JAMS makes much sense otherwise. We’re basically building from scratch but with these features it would be a great showcase of what JAMS and any modern web app on the network can achieve. We could also open source examples of code we have in place to help out.
Unfortunately its not in the immediate pipeline since its certainly going to require work from the backend team for the same too(from the vault layer at a minimum) and all those guys are focused on parsec and routing progression for Alpha-3 right now.
We certainly do feel the same way about PUSH notifications being a key component and an essential feature to have and it certainly is something the frontend team push for quite a bit, but we’ve got our hands tied for with Alpha-3 work right now from routing/vault layer.
Apart from it not being convenient to use, is there something polling and checking “if data has updated” not achieving instead of PUSH notifications right now as a workaround tho? Just asking to maybe get some details on the specifics in terms of PUSH notifications and tracking MD changes.
It’s something that can be done by polling for sure. It’s mainly that I fund the development myself so being able to avoid any work around that will need replacing aside from just keeping up with versioning and bug fixes etc is something that can save quite a lot of money to be allocated somewhere more worthy.
Totally understand you guys have your sights locked in on target and that is good. Hope it’s at the front of the queue after these very important milestones are reached.
Thanks for hearing me out and giving a straightforward answer. I don’t know that it’s enough to stop me so I’ll likely progress forward but it was something I felt could be useful feedback that would be prudent to myself and others.
Oh it certainly is and we can for sure understand what you mentioned with trying to minimise the amount of code/potential bugs to deal with and its impact on funding.
Ah not a problem at all If you do go down the workaround route , we might able to help with that via reviews/discussions to maybe limit the scope of bugs/… It’s certainly not ideal but do give us a shout and I’m sure @nbaksalyar or @Krishna can help make the workaround maybe easier where possible in the interim period.
I have a question regarding earning PtD or PtP rewards from a public ID of an app user. If a user is using an application where they can post content that is PUT and paid for by them, do they receive any rewards based off the popularity of that content? Do they need to tie their wallet to such content somehow or merely upload it?
If they can’t get a share of PtD (pay the developer) then this is definitely an argument for PtP (pay the producer) and can be used as a monetization model that is able to avoid pesky advert based monetization. Do you only earn PtD if you publish a service??
The way I envisioned it in my head when brainstorming was, a user uploads an MD that contains a unique (curated) list of xor addresses to other data, basically a playlist. The data in that list could be something they or someone else uploaded. If the uploader got paid for the use of the playlist MD that contains the list, as well as any MD/ImD’s contained in that list, then a lot of cool things can happen.
PtD as far as I understood it was to pay the gets done on the Application program file GETs. There was some murmurings that it might apply to (any) GETs initiated by the APP.
For the versions of the tale where GETs on the Application program file is rewarded then the application has the payment ID encoded.
For the versions where the GETs initiated by the APP are rewarded then the ID recorded with the APP program file is used to pay the developer.
There has not been any mention that GETs on MDs is paid PtD rewards. But hey it would seem reasonable that it would.
PtP was envisioned to pay the providers of content. This would be the network paying people to provide content that then encourages use of the network. And has a added benefit of encouraging higher quality content. People will use higher quality when possible so those providers get the rewards.
@rob What about if the app user could tie their immutable wallet ID to a playlist MD (the curated list of song data) within the app as if it was them publishing it??
This is one way I envisioned some future plans but unfortunately it’s hard to be 100% clear on these things. But if @maidsafe is looking for any suggestions?? I would highly recommend this.
and we can for sure understand what you mentioned with trying to minimise the amount of code/potential bugs to deal with and its impact on funding.
If you do go down the workaround route 
, we might able to help with that via reviews/discussions to maybe limit the scope of bugs/… It’s certainly not ideal but do give us a shout and I’m sure