Moving topics/contexts between communities
Technical Discussion
13
Posts
2
Posters
68
Views
-
@julian If context is a collection,
Moveis problematic for the same reason asDelete. I think users shouldn't move server-managed views.It would be better to introduce a companion object (or an actor) for context collection. I guess I need to say something that in FEP-f228.
-
@julian If context is a collection,
Moveis problematic for the same reason asDelete. I think users shouldn't move server-managed views.It would be better to introduce a companion object (or an actor) for context collection. I guess I need to say something that in FEP-f228.
Would
updatework better?Moveis pretty self explanatory, and I don't have any issue with a collection being moved from a collection to another collection (despite how odd that sounds.) -
No,
Moveis a good choice, but I do have a problem with itsobjectbeing a collection. I am not sure if I can implement this in my ActivityPub client application.Are you opposed to adding a companion object?
-
No,
Moveis a good choice, but I do have a problem with itsobjectbeing a collection. I am not sure if I can implement this in my ActivityPub client application.Are you opposed to adding a companion object?
Not particularly, but I am worried about adding additional complexity since it affects developer buy-in.
I'll bring it up at the next ForumWG for debate.
-
Another solution: introduce a new object class, client-managed collections. These collections should have a property that differentiates them from server-managed collections, e.g.
isClientManaged: true. And they shouldn't be paginated.I think this would be compatible with client-side signing.
But companion object solution seems to be cleaner.
-
Another solution: introduce a new object class, client-managed collections. These collections should have a property that differentiates them from server-managed collections, e.g.
isClientManaged: true. And they shouldn't be paginated.I think this would be compatible with client-side signing.
But companion object solution seems to be cleaner.
If we're going to be publishing activities regarding resolvable context collections then it may be time to introduce a new object type.
It would be backwards compatible with f228
OrderedCollections... using the new type would signify support for the various activity types perhaps...?Edit: if this is what you were proposing with client managed collections, then my apologies 😅 the naming threw me off
-
I was proposing a new shape, not a new type. It won't be backwards-compatible if existing implementations do pagination of context (I think some of them do)
-
No,
Moveis a good choice, but I do have a problem with itsobjectbeing a collection. I am not sure if I can implement this in my ActivityPub client application.Are you opposed to adding a companion object?
>Would update work better?
On a second thought,
Updateis better because posts and conversations could be addressed to multiple groups. A common example of this is a post that @-mentions two or more groups.I think updating a single property (
tooraudience) is more straightforward thanMovewith multiple origins and multiple targets. -
>Would update work better?
On a second thought,
Updateis better because posts and conversations could be addressed to multiple groups. A common example of this is a post that @-mentions two or more groups.I think updating a single property (
tooraudience) is more straightforward thanMovewith multiple origins and multiple targets.Specifically with sending
Update, I have no real objections except one cannot simply assume that two groups being addressed constitutes a cross-post.... for the simple reason that Mastodon conflates addressing with mentions.
For that reason and that reason alone I cannot infer community for any given object based on to and cc.
Now,
audience, on the other hand... is a good signal.So I am totally on board with multiple audiences being updated.
-
For that reason and that reason alone I cannot infer community for any given object based on to and cc.
Could you elaborate on this?
I think both
toandaudienceare not reliable signals. The object should be present in context in order to be considered published in the community.>Now, audience, on the other hand... is a good signal.
I thought Lemmy devs decided to address community in
toinstead ofaudience. Any news on that front? -
For that reason and that reason alone I cannot infer community for any given object based on to and cc.
Could you elaborate on this?
I think both
toandaudienceare not reliable signals. The object should be present in context in order to be considered published in the community.>Now, audience, on the other hand... is a good signal.
I thought Lemmy devs decided to address community in
toinstead ofaudience. Any news on that front?silverpill@mitra.social said in Moving topics/contexts between communities:
> I thought Lemmy devs decided to address community in to instead of audience. Any news on that front?You're right. I'm going to want to talk to nutomic@lemmy.ml about that one. I think it was a mistake to remove setting that property explicitly.
As for audience being a more reliable signal, I mean that when I receive a Create(Note), I cannot reliably tell whether it was made to a community or not. Mastodon users may tag communities in a mention, and they may intend to post the topic there, but they may also just be tagging to community as a reference in post content.
-
silverpill@mitra.social I have been reflecting on the use of Remove/Move vs Update and I am thinking that Update isn't explicit enough.
If I am removing a topic from a category, I'd be sending an Update with the group actor removed from the audience property.
However recipients wouldn't know which audience was removed, merely the new state of that context's audience.
Gli ultimi otto messaggi ricevuti dalla Federazione
-
I think the wrapping in <p> is just plain good practice because otherwise rendered content could be injected somewhere resulting in invalid HTML.
Not that browsers ever reject bad HTML anyway heh</p>
-
>Can you explain what goes on in mitra?
When mediaType is text/markdown, the entire content is wrapped in a <p> tag. This was done for compatibility with PeerTube. I think <p> was needed to create a space between the title (name) and the content, since title is prepended to content in Mitra (also a compatibility hack -- for Mastodon API clients).
-
I'd generally discourage RFC7591 in decentralized systems due to the fact that it creates client sprawl (this is currently a problem with Mastodon's client registration mechanism, which is why we created CIMDs) — every client in RFC7591 is a distinct client, with its own client_id and client_secret, which can make client management interfaces difficult to implement (e.g., every time you login on a mobile device or SPA, you'll get a brand new client_id). CIMDs solve this by anchoring client metadata to a URI, and using that URI as the client_id.
If you need to test clients using CIMDs in development, there is cimd-service however, it's currently targeting the AT Protocol ecosystem (so has a few specifics that at present there that would not necessarily make sense of ActivityPub)
-
Speaking of handling markdown. I created funfedi.dev Media Types a while ago (and just added it to the navigation). I lost interest when I saw that nobody properly handled the mediaType attribute of a note. Not that I know what I expected.
Can you explain what goes on in mitra? When mediaType is text/markdown. It changes __bold__ to <p>__bold__</p>, otherwise no paragraph tags. I'm pretty sure, I was once told to use __ for bold and * for emphasize. So my markdown should be good.
Full example ... input activity -> mitra api response
Final note: I am not sure what I would want a proper data format to do. I find the solution of W3C ActivityPub (not W3C ActivityStreams) proposes of putting HTML in content and adding source with the original, from which the HTML was generated ok. Of course, this leaves the existence of the summary and name field superfluous.
-
@reiver@mastodon.social add in NodeBB as well. Markdown first, and probably HTML too, although it will probably be sanitized to death on the way out.
-
@mariusor that's too bad. All I have left is mussels, French fries, large-scale bureaucracy, and peeing statues.
-
@reiver #WriteFreely uses Markdown by default too, but of course sends out HTML to the fediverse
-
@reiver Markdown or its subset is supported by almost every platform except Mastodon.
But PeerTube is the only software I know that puts markdown in content instead of HTML.
