Solid Outbox - how to keep track of sent messages

How can I keep track of messages I sent to someone else’s inbox? As far as I know we do not have something like an outbox in Solid / LDP.

E.g. in Solid Groups I am sending join requests to the group’s inbox. I want to keep track on the user’s Pod so that she (and the app) is aware, she already sent a request and does not need to send again.

1 Like

Hello,

I don’t know how groups work, but the best solution I have found for my notification problems is to publish the request on her profile, and send a link to the profile to the receiver’s inbox. This solves an additional problem: anyone can publish to the inbox, so the receiver needs to check that the join request has not been faked. With this system, the request is published by the person who wants to join, so it cannot be faked.

If the request needs to be private, it can be written to a private resource linked to from the profile with rdfs:seeAlso.

I’m not familiar enough with the specs, and I don’t know what the preferred way to detect faked requests is, but I think it would be a great question for the authentication panel.

@aveltens maybe you find the discussion on SocialHub of value (I mentioned Groups app there as well): https://socialhub.activitypub.rocks/t/groups-implementation/591

Edit: As you probably know in ActivityPub (which is just an extension of ActivityStreams) both Person and Group are Actors, which have both an inbox and an outbox and some other handy collections like followers / following, etc.

@aveltens I think this is more of a question about whether you want to track every message sent, or want to maintain something that’s more contextual based on a network invitation. There are plenty of ways that you could do this, but the challenge is to have a way that different applications in the ecosystem also recognize. We’re working on providing foundations to help solve problems like this in the interoperability panel, which you might be interested in.

I’ll be posting an interoperability update following tomorrow’s panel session, and will try to give a bit more context on that work overall since it will be the first interoperability panel update posted here.

1 Like

Hi @justin, I agree.

One reason I started building Solid Groups is to test the limits of the current spec and server capabilities and help evolve it where needed.

I will take a at the panel soon, and am very curious to see panel updates on the forum.

2 Likes