I think we should remove the use of public inboxes altogether. Instead, iterate on SAI Invitations. I have some thoughts captured in Social Agent Invitation and Identity Verification. I believe that we can leverage a pre-established communication channel between Social Agents to establish initial pair of Social Agent Registrations. Removing the need for any public inboxes altogether.
@elf-pavlik: I will be working as part of the project with NLnet on bootstrapping social graph and re-iteration of invitations. This will result in establishing reciprocal social agent registrations.
@justinwb: We had them as a workaround for the lack of notifications, in favor of removing them and switching to notifications
Related issue: https://github.com/solid/specification/issues/464
Currently, spec suggest two inboxes in https://solid.github.io/data-interoperability-panel/specification/#social-agents
Later on, Access Inbox is being used in https://solid.github.io/data-interoperability-panel/specification/#access-receipt
I think we should remove the use of public inboxes altogether. Instead, iterate on SAI Invitations. I have some thoughts captured in Social Agent Invitation and Identity Verification. I believe that we can leverage a pre-established communication channel between Social Agents to establish initial pair of Social Agent Registrations. Removing the need for any public inboxes altogether.
This will auto fix #227 😉