Mike Macgirvin wrote the following post Fri, 11 Aug 2023 14:35:04 -0700Thanks to a comment in one of the federated search threads, I'm currently merging our federated search implementation with opensearch. In case you missed it, I have serous reservations about Mastodon's proposed implementation. The fediverse is not a dictatorship, and ideas spread here based on merit and consensus, not decree. But I'm not here to throw rocks. I'm here to present an alternative.
Permissions are based on the 'canSearch' attribute, which is an array of actors, groups, lists, follower collections, etc. which are allowed to search each channel. A public search will contain the ActivityPub public inbox, for example. An empty array means nobody can search your stuff.
A site search is the aggregation of individual channels on the site that allow the visitor to search their content; and the instance provides its own 'canSearch' attribute for the actor record of the instance (at the site root). So each search requires permission up and down the stack with you providing the final say. This has no linkage to user discovery; which uses a separate permission.
Searches return ActivityPub collections when fetched with ActivityPub headers, Nomad collections when fetched with Nomad headers, and text/html when fetched with a browser. Pure fediverse implementations need only support ActivityPub. Would be quite happy to work with other federated communities on further standardisation and refinements. For now you can provide feedback and discuss this in the @Streams (npub1yml…x54a) group (https://unfediverse.com/channel/streams) and I'll create a separate working group if there's enough interest. Would love it if somebody would like to step in and create the FEP for this as my available time is quite constrained. This implementation will run on a rasberry pi or shared hosting using any search backend you wish to implement.
What opensearch brings to the table is a standardised and mature specification related to discovery of the search endpoint(s).
Since we already support federated search based on this model and also have long-standing support for opensearch, merging these should be not be terribly difficult -- and is currently in progress.
Cheers.
@mike (npub1nl9…fh6t)
Streams /
npub1ym…wx54a
2023-08-11 21:36:22
Author Public Key
npub1ymlv5ethpjyptpndxf5kag45v0uazzmjj5c2zezgd6fhvt2cz7dq3wx54aPublished at
2023-08-11 21:36:22Event JSON
{
"id": "5a27845b72909da20f82ff2acc9204604729a94cc97f49bd44817ca3fa2f0f78",
"pubkey": "26feca65770c8815866d32696ea2b463f9d10b729530a164486e93762d58179a",
"created_at": 1691789782,
"kind": 1,
"tags": [
[
"p",
"26feca65770c8815866d32696ea2b463f9d10b729530a164486e93762d58179a",
"wss://relay.mostr.pub"
],
[
"p",
"9fca797905b1acdbd131e3f06faec76fde872fdeb18dbb51cbfee0be2643b581",
"wss://relay.mostr.pub"
],
[
"p",
"3bfacf788e0c39b12d3e889ea7daa3ea52fa075dbe659e8728550efe1b15cd0d",
"wss://relay.mostr.pub"
],
[
"proxy",
"https://unfediverse.com/item/ee4a3999-9215-45d1-85b8-05a9be91dda9",
"activitypub"
]
],
"content": " Mike Macgirvin wrote the following post Fri, 11 Aug 2023 14:35:04 -0700Thanks to a comment in one of the federated search threads, I'm currently merging our federated search implementation with opensearch. In case you missed it, I have serous reservations about Mastodon's proposed implementation. The fediverse is not a dictatorship, and ideas spread here based on merit and consensus, not decree. But I'm not here to throw rocks. I'm here to present an alternative. \n\nPermissions are based on the 'canSearch' attribute, which is an array of actors, groups, lists, follower collections, etc. which are allowed to search each channel. A public search will contain the ActivityPub public inbox, for example. An empty array means nobody can search your stuff. \n\nA site search is the aggregation of individual channels on the site that allow the visitor to search their content; and the instance provides its own 'canSearch' attribute for the actor record of the instance (at the site root). So each search requires permission up and down the stack with you providing the final say. This has no linkage to user discovery; which uses a separate permission.\n\nSearches return ActivityPub collections when fetched with ActivityPub headers, Nomad collections when fetched with Nomad headers, and text/html when fetched with a browser. Pure fediverse implementations need only support ActivityPub. Would be quite happy to work with other federated communities on further standardisation and refinements. For now you can provide feedback and discuss this in the @nostr:npub1ymlv5ethpjyptpndxf5kag45v0uazzmjj5c2zezgd6fhvt2cz7dq3wx54a group (https://unfediverse.com/channel/streams) and I'll create a separate working group if there's enough interest. Would love it if somebody would like to step in and create the FEP for this as my available time is quite constrained. This implementation will run on a rasberry pi or shared hosting using any search backend you wish to implement. \n\nWhat opensearch brings to the table is a standardised and mature specification related to discovery of the search endpoint(s). \n\nSince we already support federated search based on this model and also have long-standing support for opensearch, merging these should be not be terribly difficult -- and is currently in progress. \n\nCheers.\n@nostr:npub1nl98j7g9kxkdh5f3u0cxltk8dl0gwt77kxxmk5wtlmstufjrkkqsk0fh6t",
"sig": "99ef21dfe328ec8b0038123fe64bfbe8ae456b451e030b30ae6d19942dcbfaeea7462c045843e9f64087895ca41e51dab4e306a0c6807d00b43a3a8584261fa9"
}