Do not understand why anyone would ever boost one of those cross-posted tweets that has the "RT" text and Twitter links in them.

To be fair I also do not understand why anyone would ever want those cross-posts to exist like that, either.

I have specifically qualified my statement to cross-posts that include the "RT" text and all sorts of broken references to avoid "not all cross-posts" responses, but I still got them. Okay then.

Unsurprisingly, I indeed believe that Mastodon is better than Twitter, and prefer seeing posts created here over posts created somewhere else.

I also think that the ability to cross-post from Twitter works against Mastodon adoption.

"Ability to cross-post from Twitter works against Mastodon adoption"

My thesis on this is simple. People choose the easiest path. If the destination is "try Mastodon", one path is "log on and use Mastodon" and the other is "set an automated cross-poster, keep using Twitter". So, people who might have otherwise committed to using Mastodon, for there not being another option to "get on it", now have the option not to.

I have observed this trend before and after the cross-poster became available.

@gargron ... at it from another point of view: Many of us have been blaming Facebook and Twitter to be "walled gardens" and "data silos" - for pretty good reasons as it's hardly possible to communicate with users "inside" if you're "outside". Shouldn't we do better and rather try to eliminate "inside" and "outside" altogether? 😉

@z428
you can't.. since those outside refuse the federation. it's not #mastodon fault, design or architecture. those making it impossible to talk to wherever your friends are, are the closed gardens, not the fediverse.
what could Mastodon do more than allowing the remapping of the "public square" on the open web fediverse?
it's up to other closed gardens to open the gates.
@Gargron

@benborges Yes, I don't disagree - it's about others to open the gates, but it's about us to make sure we don't have walls or gates at all to begin with. And, from a certain point, focussing on ActivityPub as the *only* federated protocol might be a wall/gate as well ... 😉

@gargron

@z428 @Gargron I disagree on the #activitypub bit, that's the same of saying : we should not use all the same email protocol cos it will give pop3/imap a monopoly on email delivery. Protocols are what makes the web inter-operable, hence #indieweb & fediverse could comment on each others posts simply by adopting the protocol; anyone is free to make a new interface for it as long as it abide to the protocol, that's why the web still works right ?

@benborges Difficult. I tend to agree but then again, unlike e-mail or HTTP (where essentially the same protocols have been in use for like three decades), open social networks have been pretty much about re-implementing similar ideas in different, incompatible protocols ever since. That's why, right now, Diaspora, the fediverse, Movim, .... seem like "open silos" that hardly play together.
@gargron

@z428 diaspora, movim, and activitypub also deal with different use cases, though!
- movim is an extension of xmpp status/mood, and is intended to build on personal messaging with your contacts.
- diaspora has never focused on compatibility, and has doggedly stuck to their own protocol because their entire sharing model is reversed; it's not a follower model.
- activitypub is a web technology meant to link together disparate streams of data
@benborges @Gargron

@trwnh These however seem more like different technical approaches. I doubt the actual *use cases* (as in what end users do with the system) really differ between these networks. From that point of view, in example mastodon and peertube seem way more different in use case and target group than mastodon and movim ...?
@benborges @gargron

@z428 disagree. mastodon and peertube are both fundamentally web sites, passing web documents around. a profile on a web site is a 1-many service. movim is... not that.

if you simplify the use case to "communication" then you end up ignoring the intricacies of how people actually use each system. for example, it is possible to implement a chat service entirely within activitypub, but *should* you? that's a lot of overhead for transient use cases. @benborges @Gargron

@trwnh For what I see, mastodon is more of a (micro)blogging platform focussed on smaller text messages whereas peertube is an environment for hosting video clips. Movim is closer to Facebook or Diaspora (longer posts, embedded online chat). That's the level of abstraction I had in mind, even tough on a "lower" level I agree with you.
@benborges @gargron

@z428 Even on a higher level, I wouldn't say that IRC and XMPP serve the same use case at all. You wouldn't join a chat room and expect private communication, in the same way that you wouldn't expect private communication on a publishing network. In that sense, Peertube and Mastodon both serve a "publishing documents to a stream" use case.

Whether the ultimate payload is a text document or a video document is irrelevant to the fundamental use case. @benborges @Gargron

@trwnh ... Movim (basically a communication / chat system with publishing features bolted on top) or Diaspora (a publishing system with messaging and chat added to the mix) or something like Mastodon (which might be in between somewhere). It won't matter, either, whether chat or publishing is first, whether chat is activitypub or XMPP or anything else. That's just *how* use cases are implemented, not *what* use cases are about.

@benborges @gargron

@z428 My point is less about the "how"/"why" and moreso that the protocol diversity is a direct result of use-case diversity. The Diaspora protocol was built with reverse-sharing in mind. Movim is an extension of a protocol that was built with 1-1 chatting in mind. IRC was built with live rooms in mind. ActivityPub was built to be a very general protocol for sharing data between websites. The stuff that gets built on top of those protocols can't really be built on just one protocol.

@z428 So it's not about what came first or which was bolted onto which, but rather, which use cases are naturally supported? Note that ActivityPub is currently having issues with identity management and with encryption schemes, because it was built for web servers; you can consider ActivityPub a poor base for a 1-1 chat system.

Facebook is a bad example because it's the Everything Network. It bolts together disparate experiences like chatting and posting -- and it still used XMPP for chat.

Follow

@trwnh Yes, but actually the "Everything Network" is exactly my point and (as far as I see things here) pretty much what mere end users expect, assuming the "all-in" approach makes for a rather seamless experience. That's why, in example, I see there should be tight collaboration between Movim / XMPP people and AP folks (because there might be synergies in the publishing fields, and XMPP definitely can manage the 1-1 or conference chat system). Right now, there are too many technical ...

Sign in to participate in the conversation
Mastodon

One of the first Mastodon instances, there is no specific topic we're into, just enjoy your time!