Suggestion: Focus on Creation of Bridge Microservers

[BeatLink]

Hey there, Been using DecSync for a while and i think it has the potential to be a huge game changer in serverless peer to peer computing.

Currently DecSync implementation is focused on implementing the libdecsync library into various applications like spaRSS, Flym, evolution and so on.

My suggestion would be instead to focus instead on bridging microservers. These microservers would basically be background services running locally on desktops and mobile devices. They would connect to a decsync folder and expose standardised or common service APIs that other applications on the device could connect to. This would allow decsync to be supported on any application that supports these APIs without needing to build in specific decsync code into each application.

For example, RSS feeds in DecSync are currently handled by a custom fork of FeedReader and spaRSS (now Flym). What if instead, a microservice app was created for desktop and mobile devices that could connect to the decsync folder and expose a common RSS API, like Fever or NewsBlur or TTRSS instead. Then any RSS application on these devices that support those APIs could connect to the microserver and use DecSync.

This bridge microserver architecture is already used by DecSyncCC and Radicale (both implementing CalDAV). My suggestion would be to focus on this architecture for other services like RSS.

What are your thoughts?

[39aldo39]

Thanks for the suggestion! I think it is an interesting idea, but not very useful in practice. For the calendars you are right: it is easier to implement CalDAV via Radicale as that is widely supported, but I don't think it really applies to other formats. For example, for RSS there isn't one standard. I could use an existing one like TTRSS, which would basically be equivalent to a TTRSS plugin. This might be useful but the user then has to install TTRSS as well, making it more complicated. And for potential future applications there aren't really standards I think.

Furthermore, this also only applies to the desktop, for mobile devices it isn't possible to implement a local web service, which is what the apps expect. Although now that I think more about it, on Android there are Content Providers that may be used, similar to the tasks integration of DecSync CC. That might be interesting, although it still adds complexity with an extra indirection.

What I am currently looking more into is making libdecsync easier to use for known formats. I have already started a bit but not really documented it well. I think it should be possible to make using libdecsync as easy for known formats as it would be to integrate with an API.