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 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 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 & 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.

@trwnh ... borders and apparently too few approaches to actually unify these things to come up with something that, to an end user, provides an experience on par with or even better than Facebook and *still* is less "silo" and less privacy-invading.

@z428 Even if you simplify everything and say "OK, no redundant protocols", you still end up with stuff that can't be done entirely within any one protocol, and you still end up with overlaps. SMTP and XMPP can both coexist because emailing and chatting are sufficiently different use cases despite being fundamentally the exact same (sharing text with attachments to your contacts). Should SMTP be deprecated, and should email servers implement XMPP instead?

@trwnh ... whether the "open community" lacks sort of a vision to get all these things together in a homogenous, seamless, structured way without building yet another silo.

@z428 Now we're talking about the app level and not the protocol level. The GMail webapp still uses multiple protocols; it's more akin to having a GTalk pane next to your GMail pane. Likewise, you can build an email client that had XMPP chat embedded in the side (e.g. Thunderbird, Evolution, eM Client, and so on).

I wouldn't call either part of that an "open silo". Even then, the only "silo" aspect is in incompatible data representations -- you can still build a converter or bridge as you said.

@trwnh I thought to be on what you call "app level" already all the time - as,the point of interface for end users to realize their use cases. That's what I mean, and that's where I see protocol choices as a technical detail and integration as way more important (and incompatibility way more difficult to handle).

@z428 The incompatibility stems not just from the protocol, but also from the use case. How do you handle following people inside a chat app? Do their posts get translated into direct chats with you, or do you simply not receive their posts? Do their posts get set as a chat status and then get overwritten by the latest post? There are too many questions and no one way to answer them all. The metaphors aren't the same.

@z428 We can, of course, write as many bridges as we'd like, or even make our app multi-protocol, but that's more an issue of resource allocation and actually doing all that work. It will never be transparent and seamless as long as there are different metaphors. Those metaphors are the seams between networks that serve different use cases.

@z428 So to follow Mastodon users on Movim and vice-versa, both applications need to either share metaphors, or have a way to translate between them. That can happen if and only if both Mastodon and Movim had the same basic assumptions, which they don't. Movim has no concept of Actors or Activities, and it can't generate public-facing web resources. But Peertube can. That makes Peertube more similar, and Movim less similar. The basic assumption is of following, not of chatting with contacts.

@z428 Which, again -- should ActivityPub apps build bridges with XMPP? Maybe your answer is yes, but that still doesn't answer how; it doesn't lay out any metaphors, and it doesn't really detail how the apps should work together.

All you can really say is that if Movim adopted an ActivityPub bridge, it would be possible to send DMs only and have that show up as a chat. But that would be a copy for delivery, so you couldn't do all the XMPP stuff like voice and video chatting, so it'd confuse ppl

@z428 In some sense, that Mastodon user's chat entry would be a limited liaison. No fancy XMPP stuff like read receipts, encryption, calling, presence, etc.

Is it still worth working on that integration across protocols -- or functionally, across use cases? It'd be awkward at best. And the logic gets complicated quickly. What happens if someone mentions you without being added to your contacts? Or what if your friend mentions you in some other thread? Etc.

@z428 It's not going to be impossible, sure. Multi-protocol apps exist and do these kinds of translations all the time. But it's up to those individual apps to handle multiple protocols and multiple use cases, and to figure out which translations to make. Osada/Hubzilla uses zot for permission management, but Osada also creates a limited ActivityPub profile that is missing a lot of zot features. That's fine because zot translates the concept of contacts to followers, and it already has streams.

@z428 By contrast, Diaspora is always going to have trouble with translations like that because of their reverse-sharing model. Diaspora is not and probably never will be about interoperability, because their metaphors are more important. You share with your contacts, not the other way around. Any interop with Diaspora has historically been because others have reverse-engineered their protocol and applied some complicated translations internally in their own apps.

@z428 That's kind of what makes ActivityPub so promising: it's extremely generalized, and the actor-activity-object model can be translated without too much difficulty for a lot of other stuff. And we're getting to the point that the overhead is maybe not so significant, because you can implement just a subset of the Activity Vocab, Streams, or Pub. But that kind of only really works as long as we're all passing JSON-LD around between web servers.

Follow

@z428 Sorry if that got a bit long :blobpeek: tldr: we can't build homogeneous and seamless apps if we disagree on what that homogeneity should look like. and boy are there a lot of disagreements.

@z428 (addendum: movim's primary disagreement would be that atom/rss/xml feeds are "enough", and that linking data is unnecessary. but to me it feels kind of cobbled-together to keep data unlinked...)

@trwnh Some of the XMPP crowd see this the other way: With direct messages, conferences and publish/subscribe, XMPP has pretty much everything you'd need for building something like Facebook entirely on top of XMPP, and for new message or content types (new use cases), XMPP per se is extensible by design because it also aimed at being generic back then. 😉

@z428 The downside being that a collection of extensions is less comprehensible than a full standard, you mean? :blobpeek:

@trwnh Of course. I'm by no means a blind XMPP promoter and actually I think XMPP has done a a lot to its current "state" of adoption by being too generic and open (and this way maybe not really suited very well for actual use cases) whereas AP has done a better job focussing on *something* - but: For one, I see a lot of XMPPs problems stemming from a total lack of actual clients (or both chat/conferences and pubsub). The other way round, however, I wonder whether ...

@trwnh ... it would have been possible to build something such as mastodon on top of XMPP and existing technologies just alike. From an old-fashioned hackers point of view, this feels somewhat strange in terms of "re-solving problems that already have been solved before". Rather than making XMPP a wheel more round, there now is yet another spec / standard / protocol with partial overlaps that also still is subject to becoming more mature. Same happened for OStatus and Diaspora, in ...

@trwnh ... some ways. I have the feeling that, these days, we're way faster than ever with throwing things away (or building things all anew) rather than trying to make existing approaches incrementally and gradually better. And I'm not feeling very safe to say at which point this starts being a problem from a sustainability point of view. In the fediverse, already, some of these issues can be seen in the "free network" ...

@trwnh ... becoming an overly complex and partially disjoint thing (see medium.com/we-distribute/a-qui) which, to a non-technical end user, is very likely to make no actual sense at all. 😉

@z428 I don't think the user needs to worry about protocols strictly. I think we can settle on a few different protocols eventually and naturally, but right now the protocol space is still incomplete. XMPP in a sense came too early, but it's probably the forerunner for contact-based networks (aside from email, which will probably not be deprecated). It's arguable whether Matrix can replace XMPP, since it seems to be more a development of IRC in its current iteration.

@z428 So what does that leave us with?

- Contact-based: SMTP, XMPP
- Room/channel-based: IRC, Matrix
- Subscription-based: Atom, ActivityPub

Now, it's entirely possible for XMPP to extend to the latter two (as it has with MUC conference rooms and with Movim). It's also possible for ActivityPub to extend to the former two (since it's general enough and is basically email-over-JSON with richer payloads and linked data).

But it's also possible that these distinctions will stay.

@z428 For example: even among the same category, you have to have considerations for bandwidth and synchronicity. IRC will probably continue as the synchronous pure-text connection it is. Bouncers like ZNC and Quassel can maintain a constant connection for you, if desired, but maybe that use case would best be served by forums. Chatting, publishing, etc. are all also different use cases that justify their own protocols.

Sign in to participate in the conversation
Mastodon

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!