Note : This project is still in the planning stage.

Mujammi' | مُجَمِّع

A game changing, feature-rich, efficient, blazingly fast, highly extendable and easily integrated news aggregation deamon that aims to make the process of aggregating news more organized, light-weight, secure and private.

It's not just an RSS aggregator nor a feed reader, it's a feed aggregator which act as a middle man by accessing feeds from any source using informants, and communicating with feed reeders using D-Bus and Named Pipes to display the news. It takes control of the database and it organizes everything so much that the feed reader's only job is to display the news.

---

Install


Contribute


Packaging


Q&A

---

Features

• 🧾 Free software under the AGPL-3.0 licence.
• 💪 Written in the Rust programming language.
• ...

Concepts, Definitions and Ideas

1. Informant: The part that fetch feeds from there sources and convert them to a generic format that could be stored in the database.
   • They could be Builtins or Extensions.
   • Each one is responsable for dealing with specific protocol or type of feeds.
2. Feed Aggregator: It's what Mujammi is. It access feeds using Informats, store them in a database, and provides an API for Feed Readers to communicate with it and get contents.
   • It's the core of the oporation and we can have only one of it.
   • It should run all the time in the background.
   • For simple communication with Feed Reader it uses D-Bus.
   • When we have a lot of data it will send them using Named Pipes to Feed Reader.
   • The D-Bus/Named Pipes communication interface should be good for most use cases, but if not, it is moduler, so you can create another one rather then using it.
   • It is not usual for the user to interact with it directly.
   • It's not ment to be used for huge amount of users as a web service for example.
   • It can sync data between multiple devices using a special syncing protocol and service that could be self-hosted.
   • It should support every feature a feed aggregator should have.
   • ...
3. Feed Reader: An application that display feeds and there contents to the user, by communicating with the Feed Aggregator.
   • They might also provide an interface to configure the Feed Aggregator and to manage feeds and everything related to them that the user might want to change. But no problem if this was a separate thing.
   • They are separate projects that just use the Feed Aggregator's API, there developers are able to build them as they like and users might select any one to use based on what they prefer.
   • It should not be running in the background.
   • It should not access the network by it self. It can only request the Feed Agregator for some extra media for a specific news or feed. The Feed Aggregator will take care of creating a secure and private request to obtain the extra media.
4. A notification/status interface might be implemented as part of the Feed Reader or as a completly separate project.
   • It might be an icon in the system tray or a desktop widget or a script that output some text to be displayed somewhare.
   • It should wait for a signal from the Feed Aggregator to update it's information.
   • It ment to help saving time and resources by giving the user the summary so he don't need to open the whole Feed Reader.
5. Timers in the feed aggregator don't work by the user setting a time to fetch the data. The user will categorize every feed by it's importance and rate of posting news and any other influential factor to calculate a number of interest/priority that will determine how often data should be fetched from the source.
   • The feed aggregator will run a timer for every number of priority range, every feed falls in this range should be fetched ones in a random time before the timer ends and resets.
   • User should be able to specify ranges for the number of priority, and there maximum times that will be use in there timers. (This is a global setting, not for every feed)
   • This system will be used in every fetch related thing. If the user want to fetch all the feeds now, a very short maximum time will be used for every range tell they are reseted. And if the user want to fetch a single feed now, it will be poped from the timer's list.
   • If an error accured in the fetching process, it will not be poped from the timer's list so we can try again in a random time, but an error flag will be assigned to it, so the timer could be reseted without it beegin poped from it's list.
6. ...

Installation

AUR

Not available yet...

From the git repository

You need to have cargo installed in you system.

1. Clone the repository from github

git clone https://github.com/zer0-x/mujammi.git

2. Go to the directory

cd mujammi

3. Checkout to a release tag e.g. v1.0.0

git checkout vx.x.x

4. Use cargo to install it

cargo install --path=.

Q&A

Q: Why?

• To improve the overall RSS clients experience and news aggregators in general on the Linux Desktop, since the existing clients usually use a lot of resources, don't support every feature a feed aggregator should have, and a lot of other disadvantages. Having a bad news aggregator might reduce our producivity and expose us to some privacy and security risks, which is contrary to the purpose of a news aggregator in the first place.

Q: What does Mujammi' mean?

• It is an Arabic word مُجَمِّع that could be translated to aggregator in english.