Tony/257 notification

[tonypioneer]

Pull Request Details

What issue does this PR address

• Added a series of methods related to notification.
• Added a notification icon on the AppBar.
• Added a notification centre.
• Fixed some minor issues in POD initialisation.

Associated Issue

• This PR relates to issue APPBAR: Add notification when resource shared to user #257

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

Build and run the app.

Please modify the pointed branches of SolidUI and SolidPod in pubspec.yaml to dev before merge.

Checklist

Complete the check-list below to ensure your branch is ready for PR.

• Screenshots included in linked issue APPBAR: Add notification when resource shared to user #257
• Changes adhere to the style and coding guidelines
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• Any dependent changes have been merged and published in downstream modules
• The update contains no confidential information
• The update has no duplicated content
• No lint check errors are related to these changes (make prep or flutter analyze lib)
• Integration test dart test output or screenshot included in issue #
• I tested the PR on these devices:
  • Android
  • iOS
  • Linux
  • MacOS
  • Windows
  • Web
• I have identified reviewers
• The PR has been approved by reviewers

Finalising

Once PR discussion is complete and reviewers have approved:

• Merge dev into the this branch
• Resolve any conflicts
• Add a one line summary into the CHANGELOG.md
• Push to the git repository and review
• Merge the PR into dev

[jesscmoore]

Hi Tony,
I tested this branch using the matching notepod branch. I used my standard webid, which has many notes in its pods. However on login, I got the setup pod window, which shouldn't happen. Can you figure out why and resolve?

[tonypioneer]

Hi Tony,
I tested this branch using the matching notepod branch. I used my standard webid, which has many notes in its pods. However on login, I got the setup pod window, which shouldn't happen. Can you figure out why and resolve?

Hi @jesscmoore, thank you very much for the feedback.

The current notification mechanism works like this:

When a sender sends a notification to a receiver, the system creates an unencrypted JSON file inside the receiver’s app/notification directory.

After the receiver logs in, and also during runtime every 10 seconds, the app will check this folder for new messages automatically. If new notifications are found, the user is alerted through a badge on the appbar notification icon.

The notification folder is a newly introduced directory under the app folder. During POD initialisation, an .acl file also needs to be created inside this folder.

If the user does not already have this folder, a Setup Wizard will appear. By clicking the Resources button on the bottom-right of the wizard, the user can see that this initialisation step only creates the notification folder and its corresponding .acl file.

This is why there will be a setup wizard after login.

But before the test, please back up all the notes on the POD or use a test account.

[jesscmoore]

Thanks @tonypioneer, I've now tested this well with notepod. Works nicely. It would be good to have a little tuning of this branch in solidui. Otherwise works really nicely!! Is the notification centre all internal to the app, or is there integration with the platform notification system?

1. With the notification icon in appbar, on iphone17 (simulator running iOS26.4 in debug mode), there is not space for 7 icons between the hamburger and the 'more' dots icons. The number of icons in the middle should probably be limited to 5 with others moved to 'more' in very narrow screens.

2. The list item notification text can be briefer. Suggest change the text to:

'Shared to you: [fileTitle]'
[Keep the subtitle as is]

Maybe use the info icon rather than email icon.
Suggest that the delete icon, and new symbol on email icon, and number badge on notification icon in app bar are grey rather than red.

3. Suggest also make the notification message more succinct, to something like below. It will need to have a scrollbar so that it displays when the expanded tile is shown.

[Date time]

(Next bit in bold, where id is the username part of their webid]
[id] shared the
[title]
file to you

[next bit in normal font]
with [permissions] permission

[horizontal line]
Expanding tile with label 'Details' and content in smaller text:
Date: [date time]
File: [fileUrl]
Title: [fileTitle]
Shared by: [permission granter]
Owner: [resource owner]
Permissions: [permissions]

The Delete icon should be an elevated button like the close button, but in red.

[tonypioneer]

Thanks @jesscmoore. The notification centre is in solid_notification_centre.dart of SolidUI. I'll adjust code according to your suggestions.

[tonypioneer]

The layout has been adjusted.

[jesscmoore]

Thanks Tony. Looks great. I've adjusted the notification dialog design slightly.

[jesscmoore]

Approved - thanks Tony. Noting suggest use intl for date processing

[jesscmoore]

One more thing to consider:

On press 'delete' button on notification, it is calling deleteFile(). This has a revocation step before the file is deleted on the pod, which is triggering an error. It looks to be failing because there is no acl for the notification. It raises the question of whether the notification should be stored on the sender's pod or recipient's pod.

@gjwgit @anushkavidanage @tonypioneer - thoughts?

Noting that it is writing a provided file title field to ttl, where the title could be sensitive information.

Are there design precedents that we've adopted?

flutter: Error revoking permissions to recipients of user' note: Exception: Failed to get resource https://pods.solidcommunity.au/jesscmoore/notepod/data/notepod/notification/1776147344814.json.acl
flutter: Warning: could not revoke permissions for "notepod/notification/1776147344814.json" (ACL may not exist): Exception: Failed to get resource https://pods.solidcommunity.au/jesscmoore/notepod/data/notepod/notification/1776147344814.json.acl
flutter: Individual key for "notepod/notification/1776147344814.json" does not exist, do nothing.

[jesscmoore]

There is a design question impacting transparency. Should solidui call sendNotifications() to send a notification when permission has been revoked? My preference is for yes. Currently solidui only sends a notification when permission is granted. My preference is sending notifications on permission revocations as well as grants. As it is useful to know.

Comparisons:

social apps - facebook doesn't tell you if you are unfriended, other apps will remove a group chat, or just not update you group chat, if you've been removed from the group. They don't send you a notification.

With Solid based apps with file sharing, a file that you loose access to disappears from your app file lists. Which would seem odd if you did not have any notice that it was happening.

[jesscmoore]

solidui notifications has raised an architectural design question. Tony's great work on the notification centre has created a publicly append-able notification folder in pod's of people using solidui based apps with a folder level ACL, or will once merged. Notifications are unencrypted, using POST via createResource() to write to the recipients appName/data/notification folder. This architecture makes it easier for app to check for new notifications by reading the user's notification folder every 10-30sec. In this PR, notifications are being written to the pods of recipients of permission granting operations, however the design should work for other types of notification applications which may have higher or lower sensitivity.

Should our apps design for writing to other people's pods without a negotiation and their consent?
My premise is that new data files by default are written to the creator of the content?

The exceptions are edge cases with accepted consent so do not really break that design model:

1. user a has given write access to one of their files, which user b is editing on user A's pod

2. user a has transferred ownership of a file (through agreed gift or sale) to user b, which moves it to user b's pod.

The current architectural design for notifications raises 2 issues:

1. Storing otherwise encrypted data in unencrypted form: In the notepod implementation of solidui notifications, where the recipient has read access to the file which they are being notified about, the object identifier being sent is the normally encrypted title of the file content is being included in the notification text. This is storing data that is normally encrypted on the owner's pod, and writing it unencrypted in a publicly accessible folder on the recipient's pod. We want to be careful about such design decisions. In Nebraska recently, a mother has been prosecuted and sent to jail for unencrypted conversations with their daughter discussing reproductive health on Facebook Messenger, that they thought were private, but which were somehow intercepted. We don't know to what use a solidui based app could be built.

2. Spam prevention: In Solid based apps, users will need to in most cases pay for storage. Publicly append-able folders, raise a risk of user's paying for spam filled folders. We live in a world where user's don't pay for app data storage (except where that is core to the app service), because they're being encouraged to write their data to the app company's data store, who is monetising and gaining more value than the cost of data storage.

There are alternate ways that Tony's user friendly design could be implemented.

1. When notifying about access granted to a file it could always include the fileUrl rather than allow the file title, but a 2nd operation could query that and populate the title if read access given. This is better as content designed to be encrypted, stays encrypted, resolving issue 1, but not issue 2.

2. An alternative option is adopting a design principle that data is stored on the pod of the content owner (usually the creator). Ie having notification files in the notification folder of the person that creates the notification. In this way they are just another type of file. The notification list would be built by reading the permission log, filtering for urls containing 'notification' in path. And a notification could be shared with read+write access such that the recipient can read and delete it. The notification polling interval could be lengthened to 60sec, if it is also decrypting these files, or performing a 2nd process to decrypt linked file content. To reduce lag, the second step could only be called on opening a notification, rather than the list view. Or just like our other file listing use cases, eg notepod, personallibrary, the list is formed and content decrypted to display useful data in the list view. This method would resolve issue 1 and 2.

[gjwgit]

• Blocked for now awaiting discussion
• Notifications are publicly visible and could be disclosing private information
• Conflicts require fixing.