zleap
commented
3 years ago So if this needs to use any sort of Analytics, I found this https://matomo.org/ which describes it's self as "Google Analytics alternative that protects your data and your customers' privacy"
I am not sure if this is free software though. So it could be more of an add on option.
Summary
A search feature where I can discover members of and in my professional social network
Basic example
As a member of an instance When I am on the search page And I search for "Carpenter" Then I get a list of all profiles with "carpenter" in an attribute that is visible to me And in that list are my contacts, anyone on my instance and anyone who is contact of one/more of my contacts So that I can search for people in my network.
See the figma scetches for more details
Motivation
Why are we doing this? What use cases does it support? What is the expected outcome?
Detailed design
Please read the blog-post explaining the feature[1].
TODO: should we copy-paste and/or rephrase that blog-post in here?
Drawbacks
Searching "contacts" requires a search index to contain any contact, regardless of the instance they use. Searching "to me visible attributes" only, means an index per member: my indexed attributes are different from yours, even if the index contains the exact same people: the visibility and therefore searchability of attributes may differ between us. Searching "contacts of contacts" requires this index to maintain not just my contacts but their contacts too. Pushing changes to attributes and profiles over AP into indexes requires your instance to push any changes you make to your profile towards mine. This is to be expected. However, when you have Anne as contact, and Anne changes an attribute, Annes instance will push those changes to your instance, as expected. Unexpected to Anne, however, is that your instance will now push those changes to my index too. But since this applies only to public attributes the result is not unexpected. Pushing changes to profiles over AP causes load on the receiving server. A larger network graph makes that effect larger.
Limiting the amount of indexed profiles helps against large and fast changing indexes. Limiting the amount of attributes per profile also helps here. But both can cause unexpected results where people expect to see a certain (long tail) result, but don't, as the attribute or profile is pruned from the index.
Removing attributes or setting attributes from public to private will be pushed across the network, but instances may choose to ignore this, keep the old settings or may fail to update them due to technical issues. We cannot guarantee that information that was once public, is removed from indexes with Activity Pub.
Alternatives
Adoption strategy
Basic feature. Should be in initial release. Could be divided into phases to keep the more complex (private fields, contacts-of-contacts) for later moment.
How we teach this
Search is a main feature, behind a primary menu item on the primary menu. Difference between "my contacts", "contacts of my contacts" and "people on my instance" must be made very clear in the UX. Attributes that cause a match and the item to be returned, must be highlighted so it is clear what causes the hit to be returned. It must be clear that search is only for profiles and not "updates", or other items. It must be clear that returned results are based on "last known data", and that data may have changed but is not (yet) updated in the index and results.
Unresolved questions
Tech to use for indexing. Client-side: fuse.js, etc. Server-side: in PG, Elasticsearch, MeiliSearch etc. Should this be a separate service and feature, to be enabled by instance admins?
Footnotes and references
[1] https://fediverse.blog/~/Flockingbird/finding-people-with-flockingbird
This RFC template is modified from the React RFC template