It is not that they should, but could be implemented outside of a forge, and also I think many scenario’s will be unlikely to be ever adopted in forge software.
For instance forges are unlikely to store and process global aggregated timelines of project activity, which costs gigabytes of db space, eats processing power. History of message exchanges mostly does not need to be recorded, messages can be discarded after they updated the project. But a dedicated FP instance may sit right there for that purpose.
Also consider all the scenario’s where - even though project activity is public - you don’t have control - e.g. admin or other types of privilege - of the forge or repo. Can’t say “Hey, I have this interesting thing I want to do with your project data, can you make some config changes and install this plugin?” and expect it to happen.
That aggregated search service… does it need to maintain a long list of all known forge installations to get its data, or does it simply need to subscribe to a single FP relay instance (or a small whitelist of those)?
We might have a vidcall one of these days to discuss ideas… some of this is hard to convey in typed text 