App State Storage(RSS Reader)

There's a range of small apps, like TODO lists, note-taking apps, etc., that simply need a network-accessible place to store application state like settings and basic content. These are a great fit for Edsu: in particular, users won't have to set up a different account for each little app, even though each one is likely to be written by a different dev and hosted at a different domain.

Take for instance, an RSS reader. At its most basic, it only needs to store two pieces of state: which RSS feeds the user is subscribed to, and which items on those feeds they have read already. Your app could start using existing open source code such as found here here, and keep the state in Edsu instead of IndexedDB - essentially porting in the Edsu-specific code from the Hello World App, i.e. use the StorageBasic library. That's all it would take to make it both state-storing and multi-device.

Of course, since Google Reader was murdered there hasen't been a shortage of contenders sprung up in its place. An open source Edsu version would have several advantages:

First, it could be made to be "wget forkable". Since all state is stored with the user, you can copy the entire app (including your settings and read history) just by downloading the HTML, Javascript, and CSS and re-uploading it somewhere else. From there you could make whatever changes you like. Of course, this requires either that the app is written in non-compiled Javascript (i.e. not minified or run through, say, React's compiler), or has source maps.

Second, and alternatively, it could be collaborative. Because Edsu apps are comfortable on static hosting, you could host the source on a service like GitLab, and have it build to a static page also hosted on that service. The dynamics of the development process would then be much more like desktop or server apps - no one has to manage a server, authority can be distributed such that anyone with commit access can push live, etc.

Third, it would be difficult to "monetize". Because typical web apps require the developer to managing hosting, user accounts, etc. it's perfectly reasonable for them to want to be compensated for the hassle of all of that. Naturally, then, the ads and social features start showing up, etc. Edsu apps are fire-and-forget. You put your code up and then you're not responsible for it - much the same way that desktop apps are. So there's both less incentive to monetize, and more opportunity to fork the code and remove all the cruft.