RFC Updates - Auto-update and getting notified about activity in your professional network.

[berkes]

Summary

When a contact changes important info on their profile (such as a bio), I must be notified. When a contact changes less important info on their profile (such as a resume entry, contact detail, aspiration or competences), my copy and search index must be updated without me being notified of this change.

When I am tagged, annotated, related or followed, I must be notified.

Basic example

As a member
When a contact changes their bio
Then I see that change in a "my updates" timeline
So that I can see when someone changes primary information such as a job position.

As a member
When another member follows, tags, annotates or relates me
Then I see that event in a "my updates" timeline
So that I can see when someone interacted with my profile.

See the figma scetches for more details

Motivation

A lot of activity-pub "communication" is invisible and used to keep my contact list up-to-date. This should not lead to notifications that disturb, spam or otherwise pulling members into the app.

But some changes are important enough to warrant a notification. So that I can see the network is active and actively used. And so that I am kept aware of other people's tags and annotations on my profile.

Amount of Updates depend on the activity of my network and only indirectly on my own activity. This makes it a good feature to show that my network is active and that flockingbird is growing or evolving.

Detailed design

Drawbacks

• Notifications can be abused to bully or spam people. Moderation tools are required to mitigate or solve this.
• Push notifications can be considered very intrusive and annoying, especially because I don't have any say in the activity of the entire network. This is solvable with proper notification/mute settings. But those add complexity. Just presenting and not pushing notifications can be a solution too, but that removes the "pull back" effect.
• Pulling back people by sending them notifications is an often (ab)used trick by social networks to increase activity. Being entirely silent is a solution to this, but comes with the downside that the network may appear dead in a dampening manner (It appears dead, therefore I don't use it, therefore it appears dead).

Alternatives/Additions

Including updates from other networks in the person's updates. E.g. when my contact has a (verified) mastodon-account in their contact details, we could include any new "toot" that person makes in "my updates". Making "my updates" a collective inbox of all (public) social activity my contact performs on various activitypub and non-activity-pub networks and services. This warrants its own RFC, though.

Allowing my contacts to actively write updates (toots, status-updates, stories etc) which then appear in "my updates". This adds a social-network feature that overlaps with existing networks. If considered, this warrants its own RFC.

Interaction with updates: boosts/re-post, replies, likes, etc. This is a per-update-type consideratioon and is to be discussed in their own RFCs: not all updates warrant "boosting/reposting" for example: it makes no sense to re-post a "X is following you", but someone adding a tag to your account "X tagged you as 'absolute expert in FizzBuzz'" may make sense.

Not offering "my updates" at all, but leaving those to e.g. mastodon to handle. This removes all visible "updates" features from flockingbird and instead offloads them to (one of) my existing mastodon/pleroma etc accounts instead. This simplifies the model somewhat, but since we need to update contact details and search indexes anyway, it does not remove the need for federation. It only removes the visibility of some updates.

Adoption strategy

It is a primary feature under a primary menu item on the primary menu.

How we teach this

By re-using familiar patterns from existing social media, we can leverage familiarity with existing social media to let people discover the feature. Updates, or "timelines" are common and well understood features.

Unresolved questions

See TBD under alternatives.
Features to curb or silence push notifications.
Should we send push notifications at all, or just present notifications on a users' profile.
Should we email members when they have unread notifications?

---

Footnotes and references