betula_federated_search.myco

A **federated search** system is one of the features I want to pursue in [[Betula]]. Per my plan, it will be part of my Bachelor's thesis. The whole model is quite simple, and I'm describing it here for future reference.

**What is federated search?** Federated search is a feature that lets you see bookmarks from other bookmark servers, which are Betula instances, most of the time, but due to the federated nature of Fediverse, this is not guaranteed. Compared to regular search, which is straight forward to come up with, federated search needs technical and ethical considerations.

**Consent.** According to my intuition, federated search should be enabled only if they are //mutuals//. Being mutuals doesn't really mean much on the Internet, but it does imply some level of trust between the actors. In the future, profile flags like //Everyone can search me//, //Mutuals of my mutuals can search me// or //Even mutuals cannot search me// might also make sense.

**Where the search is done.** Other Fediverse software usually stores every incoming Note there is, and the search is conducted on it then. This approach makes sense and doesn't make many network requests. I however would like to make many network requests instead, because it gives other instances more agency, makes architecture simpler and ensures matching bookmarks are up-to-date. Introducing some caching is a good idea at some point, but it's not a priority.

**Search privacy.** When a federated search is made, every mutual gets notified about that. Knowing that, and knowing that a federated search is something one would explicitly want to do, rather than do all the time, I think federated search and regular search should be different actions.

img { https://private-user-images.githubusercontent.com/22562024/363702851-a88fbc5f-babe-4da1-9278-ecdec599ea82.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjUyODM2OTgsIm5iZiI6MTcyNTI4MzM5OCwicGF0aCI6Ii8yMjU2MjAyNC8zNjM3MDI4NTEtYTg4ZmJjNWYtYmFiZS00ZGExLTkyNzgtZWNkZWM1OTllYTgyLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDA5MDIlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwOTAyVDEzMjMxOFomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTc0NTE5Yjk4YTkzZDlhMGM5M2RkMDYyZWVlNWI3YTUxNTYyMTMzNzZlMDM3ZDMxNTdjYTg4NDVhNWRmMTExMjcmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.TVolesmVjUVvQ74PPl3zZNPXGdvZFSjlsBQW7chHHtQ { On this picture you see the //Search mutuals too// button on the regular search page. You press it and only after that you see federated results. This way is explicit. Maybe it should be a checkbox instead. }}

**Protocol.** The same endpoint as regular search, but with an AP-related Accept header. It would return a `Collection` object with `Note`s that are the same as those sent to inboces. Mutuality is to be checked too, of course.

= See also
=> links>/tag/federated_search