Quoted posts
-
@[email protected] @Christian-Stange @[email protected] I think I disagree that a conversation need mark that it is a "forum". It explicitly flags that the thread is different from microblogging, but why shouldn't microblogs mark their conversations instead (I ask purely to play devil's advocate because it isn't feasible nor realistic)?
Especially in this case when you yourself said it's a cultural problem (
agreed btw), the distinction is especially meaningless to the end user, who doesn't give two cents whether they're replying to a microblog or not. -
@[email protected] it's a cognitive dissonance that demands that their content be given the absolute maximum reach with the absolute minimum of repercussions.
-
@julian It's interesting how different platforms implement things. Some platforms, like Friendica, tell you which platform someone is using by showing a little icon next to their name on all of their posts (Mastodon icon, Hubzilla icon, potentially a NodeBB icon, etc.), whereas Mastodon makes it appear as if everyone is on Mastodon. Some Mastodon users are not even aware that they are talking to people on other platforms.
The reason why I say indicating that it is a forum or group discussion is useful is not just the cultural issue, but also because replies to forum posts are distributed differently than a normal post. You are not just replying to your followers and the person who posted, but also to everyone following the forum (or forum category).
But, this is something that is nice to have, and not needed. It just is useful information to have. And I doubt that platforms like Mastodon will make such a change anyway.
It's also interesting to see how platforms that pre-date Mastodon implement things versus platforms that came later and are influenced by Mastodon. -
@[email protected] I think it's a neat thing to show the software icon next to a post.
... but at the same time, think about who you want to use your software. Software geeks? Totally on board with that.
... but everyday people won't know what they're even looking at, and this (among other items people constantly bring up re: explaining ActivityPub) is all stuff that should be abstracted away from the end user.
It's not a matter of "before Mastodon" and "after Mastodon", at all.
-
@julian
It's not a matter of "before Mastodon" and "after Mastodon", at all.
I was trying not to state this so bluntly, but basically, platforms that came before Mastodon has blockquotes before Mastodon existed. We did not get rid of them in 2016, and we aren't getting rid of them now.
So, even if you implement this proposed feature, which is your right, some platforms will stay with the tried and true blockquotes. -
@julian By the way, edits don't appear to be appearing on NodeBB. I fixed a typo, but NodeBB still displays it.
-
@julian Or, to put it more diplomatically and to give a little context, this argument over blockquotes has been going on for about 8 years now. I don't think everyone is going to be on board with a single solution.
-
@[email protected] at it's core quote posts and block quotes are separate constructs. I have no plans to disallow users from making block quotes (not to mention there's no way I can even do that).
-
@[email protected] FYI I just tested editing against activitypub.academy, with successful results.
-
@julian I don't think that will matter. People who want a quote that cannot be deleted with figure that out and will pick the method that makes the quote undeletable. It seems like a lot of work for something that people will simply bypass.
-
@julian To be fair, platforms that don't have quote posts might be interested in this, since they can offer quote posts without the risk.
-
that's a bit simplistic imo. software doesn't matter, sure; what matters is what the software lets you *do*. but "interoperability" is not a goal in itself. it's a means to an end. for different software that let you do fundamentally different things in fundamentally different worldviews, there can be no meaningful interoperability.
example: fedi has concepts and abstractions for "posts" and "profiles". what happens when you don't have these same building blocks?
-
infinite love â´³replied to infinite love â´³ last edited by
@silverpill @julian i posit a different goal, at least for myself: empowering people with effective tools by which they can express themselves.
i'm posting this from mastodon right now, but i could just as well be posting this locally from within nodeBB. the federation is irrelevant, and in some cases, the federation is actually a burden. it creates the seams in UX. federation is a boundary that information crosses. the goal of a discussion form is to get information across various interfaces.
-
infinite love â´³replied to infinite love â´³ last edited by
@silverpill @julian reframing it in terms of information and interfaces, of data stores and transports, we find that there are multiple ways to participate in a centralized conversation:
- by web app + sign in (local or federated credentials)
- by HTTP POST to an endpoint (plus additional protocols on top)
- by emailing a certain address, if you wanted
- in theory you could physically send a letter to some building, if that was agreed upon beforehand, to manually enter it into the database... -
infinite love â´³replied to infinite love â´³ last edited by
@silverpill @julian so the exact protocol and its finer details are less important than what you can *do* with that. the goal is to make information reach your destination with minimal information loss.
in that sense, whatever subset of whatever fedi-adjacent protocol you adhere to is only useful insofar as it allows ingesting information without missing anything important.
and when it comes to publishing information (a separate concern from discussing!), you again likewise have interfaces...
-
the primary publishing interface we have is the Web. that should be the primary focus, not "publishing to the fediverse". the fediverse shouldn't be the end-all-be-all. we shouldn't be poorly reinventing the Web from first principles.
in a similar vein, the "network" is made up not of fedi nodes, but of mutually intelligible interfaces for information. instead of negotiating an exchange of content, it is just as valid if not moreso to negotiate an exchange of *identity*.
-
J julian forked this topic
-
infinite love â´³replied to infinite love â´³ last edited by
@silverpill @julian given this framing, it is incredibly limiting to say "the network consists solely of URIs hosting JSON documents which contain an inbox and an RSA publicKey which is used to generate a Cavage draft 8 Signature on an AS2 Activity payload of a certain shape which is then delivered to another inbox via HTTP POST with a certain Content-Type, after which the activity will be unwrapped and discarded... no exceptions to any of this" (etc)
because maybe there's better ways.
-
infinite love â´³replied to infinite love â´³ last edited by
can the network not consist of all manner of agents whose identities can be established by all manner of methods? in the same way TLS negotiates an encryption suite, a generic "TLI" can be used to negotiate an identity proof without relying on TLS client certificates.
can the application layer not similarly negotiate a semantic profile for which data models, serializations, etc are supported, and what will be done with thr payload?
