Transmit the URI of a post as an additional information

[annando]

The Diaspora protocol completely relies upon the GUID of a post, comment or like. This works fine, but has got side effects when systems do speak multiple protocols.

For example systems like Friendica, Socialhome and Hubzilla do speak both Diaspora and ActivityPub. So it can happen that these systems do communicate with either one or both of the protocols at the same time. This means that we need some way to determine if a post that is transmitted via AP is the same that had been transmitted via Diaspora - and vice versa.

Diaspora uses the GUID, ActivityPub is using the URI of a post to reference it. These are two different ways.

For AP there is an additional field that transports the Diaspora GUID which is used on both Friendica and Hubzilla. (For Socialhome I'm currently unsure).

But currently there is no field for the Diaspora protocol to transmit the URI of a post as well.

So I would like to suggest defining an additional (and optional) field that compatible systems could use with posts, comments and likes. This field would then transport the URI of that post/comment/like and the URI of the parent post in the case of a comment or like.

I do suggest using names like uri, parent_uri and thread_parent_uri.

Diaspora itself doesn't need to handle these fields actively. In a case of a comment or like it just had to store and forward it, to not break the signature (but AFAIK this is already the case). But I would prefer to have it acknowledged and documented on the Diaspora side.

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[denschub]

The diaspora* protocol has spec-level support for fetching entities under the stable URL GET /fetch/:type/:guid. For example, my reshare of the recent spider-comic would be fetchable via GET https://pod.geraspora.de/fetch/post/628ed590c9ae0137e2fc268acd52edbf. Obviously, this only works for public entities, as we do not allow fetching privates.

The fact diaspora* entities do not have an URI is not a mistake, these entities are not identifiable with an URI at this point in time. Eventually, we might be able to replace the GUID with a fully qualifying diaspora:// URI.

The URLs for viewing a post in the web interface are not stable and might change whenever we feel like it, which is why they are not part of any specification; and likely never will be. Therefore, I'd rather dislike the idea of you or anyone else building applications that rely on those URLs.

Let me know if this resolves your inquiry, and if not, please let me know why so we can figure something out.

[annando]

It is important to emphasize that this issue doesn't proposes any changes inside the Diaspora code. It is a request to add something to the documentation of the protocol. The other systems (Friendica, Hubzilla, Socialhome) just need a common ground to exchange that extra bit of information.

The URI that would be used is the ActivityPub URI that has to be resolvable due to the way the protocol transports and verifies content. But Diaspora doesn't need to do anything with these fields, besides relaying them (what it already is doing).

[Flaburgan]

That does answer Dennis question, is his answer enough for you, or what would you want to add to the spec exactly? diaspora://[email protected]/post/guid is the way we identify a post at the moment, is that enough or do you need a route which would answer to an http GET request?

[SuperTux88]

It is important to emphasize that this issue doesn't proposes any changes inside the Diaspora code.

While that is true, it still affects diaspora, because when you add something to relayables, the pod needs to store everything in the database, that's why I don't want to add additional fields there just because we can.

Why can't you create the URI based on the author and the guid field? I mean all information to create the URI are already there, there is no need to federate (and store) duplicate information. Diaspora can already create diaspora:// URIs based on the information we already have.

[denschub]

If I understand your proposal correctly, you want us to add support for arbitrary payloads inside relay'ables that we receive, to make sure that you can associate interactions on said relay'ables (like a comment or a reshare) back to the original AP post. Please correct me if I got something wrong.

You're asking us to add a field to our protocol to support your hack around AP/AS. Diaspora* claims no support for AP/AS whatsoever, and I'm sure we've made it very clear that we're not interested in doing so at this point.

The fact that Friendica and some other projects relay AP posts and comments to diaspora* is, to me, at least, actually a huge concern. You're ripping content out of its environment, and you throw it into a context where the originating network has no control whatsoever. Quite frankly, it's almost like relaying AP posts straight to twitter because Friendica wants to support both Twitter and AP, and then asking Twitter to please include the AP URL in the reshare payload when someone reshares one of those posts. (Granted, we're not twitter, but that won't change that accepting your proposal kinda makes no sense.)

If you think relaying AP-based content to diaspora*-based networks is a good idea, nobody can stop you, but it's your responsibility to get it right. If you decide to send a post or a comment from AP to diaspora*, then you have to generate a GUID for diaspora* to accept the entity in the first place. Since diaspora*s protocol is very clear that we will take and use the GUID as a unique identifier for said item, you can trust that diaspora* will return the same GUID every time where that entity is referenced. I'd also like to highlight that our specification on GUID formats is very relaxed, and while you can't put a plain URL into the GUID field, there is a lot of space to build something identifiable.

When Friendica decides it wants to transfer https://activitystuff.example.com/alice/comment/42176442 to diaspora* with GUID=7ec4f217f9ea4c6595e5060f9c401271, then building and storing that association is Friendicas job, not ours. Everything else would be implementing a hacky workaround to support a hacky workaround.

[annando]

It is not "ripping content out of its environment", When for example someone starts a thread on Socialhome or Hubzilla and the content is transmitted to Friendica via the Diaspora protocol, Friendica could fetch the URI out of the post. When the Friendica user then would answer to that post, the person could transmit the comment either via the Diaspora protocol or via AP. By using Diaspora and transmitting the URI, the Socialhome server could then relay the content not only via Diaspora, but also via AP.

These fields would help in "mixed protocols" environments where both parties speak the Diaspora protocol and ActivityPub. Due to the different ways of signing posts and checking for validity of the posts, these fields couldn't - in any way - be used for transferring posts or comments from Diaspora to (for example) Mastodon or from Mastodon to Diaspora.

@SuperTux88 I cannot create the URI out of the GUID, since every software is free in deciding how their URI looks like. The only way to work around this was some kind of "capabilities" endpoint that could return the URI scheme. But the prerequisite for this would be, that the URI would always contain the GUID - which is not guaranteed. (I'm not sure if Hubzilla does so)