All updated mastodon instances use activitypub for federation between themselves and only use ostatus when federating to gnusocial instances. I'm not sure of the version where this switch happened, but instances not updated to that version would still use ostatus solely.
  
If I understand https://github.com/w3c/activitypub/issues/228 correctly activitypub is implemented by MediaGoblin....

My understanding is that:

    OStatus is a decentralized social networking protocol made up of several other protocols (Atom feeds, Activity Streams, PubSubHubbub, Salmon, and WebFinger)
        GNU Social and Mastodon are two server software applications that implement OStatus
    pump.io API is an interface to the pump.io server software (Activity Streams, OAuth, Web Host Metadata)
        identi.ca is a pump.io instance (not accessible right now), GNU MediaGoblin is a server application that currently uses a pump-like API
    ActivityPub is a proposed decentralized social networking protocol
        GNU MediaGoblin is a server application that will likely implement ActivityPub

How do these protocols interoperate? Does ActivityPub completely replace OStatus, or only the Activity Streams component?
  
AFIAK Mediagoblin did have a GSOC 2017 goal for ActivityPub but it doesn't look like it was worked on as the Savanna git's federation branch was last committed to 22 months ago.
http://git.savannah.gnu.org/cgit/mediagoblin.git/

I've been hoping for some interaction with ActivityPub, but at least since they use PostgreSQL at the very least the database itself can store JSON in the same format ActivityPub sends
It's just a matter of someone coding it.
  last edited: Wed, 12 Apr 2017 19:51:03 +0100  
  
@Maria Karlsen I always had the same doubt! Didn't look for an answer but I like think it is the debian swirl ;)
  last edited: Wed, 19 Apr 2017 15:40:29 +0100  

Encrypted content

  
  
about #federation

Mike MacgirvinMike Macgirvin wrote the following post Sat, 08 Apr 2017 00:59:56 +0100
How to Federate the Social Web
So there are two web communication services and you want to federate them. Great. You're probably thinking "Let's just all use the same protocol." Easy.

You couldn't be further from the truth. Let me give you an example of what it takes and some of the things you need to consider and problems you *must* resolve to federate two different web communication systems.

We'll start with identity. Who are you communicating with? How do you find them? How do you connect with them? But let's step back to the top. What is an identity anyway?

Does the service use webfinger addresses?

Does it use URLs?

Can an identity be used on two different servers simultaneously?

Can an identity move? How?

Let's say it uses webfinger addresses. What characters are allowed in a username? What if these aren't all supported on your service? Or what if you allow more characters than are allowed on the other service? What do you do?

Are there length restrictions on the username? What are they? How do you resolve differences?

Does the service use "old webfinger" (host XRD) or "new webfinger" or something else?

Is everything you need to communicate with the person available in webfinger? (Highly unlikely.)

What other files or resource do you need to check to find all the information you need to communicate with them? How many of these resources do you need to check before you have enough information to continue?

Does the service allow http only or self-signed certs or any certs which are not "browser valid"? (This affects images and embedded content appearing in remote streams, as many browsers will either not display it or pop up a warning, or in some cases hundreds of warnings if your service is decentralised. It also affects whether you need to fall back to http if an https request fails, potentially doubling the number of lookup requests).

Does the service support privacy? What do you do if it doesn't and a member on your service tries to send a private message to them?

Does the service support private photos? How are these accessed? Are they fetched through an authenticated channel, or embedded? If they are embedded, what are the size restrictions on a message? Can the private photo fit in that size? Will it even be recognised? If authenticated, how do you authenticate exactly? Does this require a popup login box in the middle of your social stream? What if there are more than one of these in your stream? What if there are hundreds? What login do you use? Your own? Or some other login on a different system?

Does the system support private mail (DM)? Does this work from other services? What do you do if it doesn't?

Hashtags. Can they be one word or multiple words? If multiple, how does the service decide where the hashtag ends? Are there length restrictions? Character case restrictions? Character set restrictions? How do you resolve the differences? Are the hashtags linked on the outbound site or on the inbound site? (The latter tends to lead to large centralised servers because small sites are starved of hashtag content.)

Mentions. Same questions as hashtags. Can you mention a person with a webfinger address? What do you do if somebody in a private conversation mentions somebody not included in the conversation? Does this change the privacy?

What is the markup format used? Are there any hacks you need to add to this particular service to support their markup format?

What are the length limits of a post? (This was mentioned earlier w/r/t embedding photos, but now we're just talking about text.) How do you resolve differences in length limits? Are these discoverable? How exactly?

Is there a way to flag a post as adult or inappropriate?

Does the service provide groups/forums? How are these addressed? Can they be mentioned? How? Can they be private? How?

Does the service allow "wall-to-wall" posts? If not, are they able to recognise wall-to-wall posts created on another service or are the posts all incorrectly attributed to the same author?

Does the system support events? Are they timezone aware? Are these iCal enabled? If not, how do you convert iCal information so that it is not lost in federation?

Do they support emojis and/or emoticons? How are these designated? If emoticons are they converted on the sender or receiver side?

Can you retract a private mail message? How?

Can you retract a post? How?

Does the service support editing of posts? How?

Can you "expire" a post/comment? How?

Do comments to your posts require some service specific metadata such as signed XML fields in order for you to federate them to the other service? What if the comment author was on a system which does not federate with the other system and has no concept of requiring signed XML fields? What do you do?

Does the service support 'dislike'?

Does the service support likes of comments?

Tags in comments?

Mentions in comments? What happens to these?

Sub-comments? To what level? How do you collapse them if you service doesn't support the same number of levels?

Does the service support "apps"? What if it doesn't and the post only contains a single embedded app with no text? Do you send it?

Does the service provide a directory?

Can you request friendship/connection/follow from the profile page if non-authenticated? How?

Embedded content - what services are supported? Which are not supported? Can you embed a map? How? Is there a blacklist/whitelist? How do you know in advance if your embed will actually make it "intact" or not?

---

I came up with this list in under ten minutes based on real-world experience implementing federation between systems. I'm sure I could go for several more pages and still only scratch the surface of compatibility. So if you wish to provide service federation between two providers, these are all questions you need to ask and find answers for. "Just use Activitypub" or "Just use OStatus" isn't going to fix or answer any of these real-world examples.
  
thinking even in UNO , and its interaction with other networks....

federation with diaspora is broken, all pods with version ≥ 0.5.6.3 do not receive our comments or like in the posts started from diaspora.
Is a 'crippled' federation.
(and  I have also  some problem with the new versions of friendica - already talking about federation)

The main problem with diaspora is that the majority of the pods today use a version ≥ 0.5.6.3 ...

cc @Channel One+ @Redmatrix / Hubzilla Support Channel+
  
The biggest need we have is neutral communication between project developers, free from rock throwing.

This was one of my biggest goals towards the end of my tenure at Diaspora. It is a very long, frustrating process - I've talked to quite a lot of people in different project spaces, and some of them do indeed like to throw rocks. Not Invented Here Syndrome sucks. So does settling on the most watered-down thing for cross-platform communication. But we all have to start somewhere, and I believe that many projects have good pieces to the puzzle.

This Jason have an account in hubzilla? Did he try to know hubzilla? did he try to talk with diaspora from hubzilla? Did he try to understand federation problems, communication problems ? Did he try to create connections from hubzilla?
He have a friendica account ? He tested a friendica account?


I get that perhaps trying out other platforms sets a good precedent - but it doesn't necessarily make you any worse of a person for not using other things. Some people within the federation are totally happy with the one platform they're using, and their desire is to simply get their platform to work with other platforms. Some people believe that confirming to protocols and setting up proper endpoints is all they need to do for their application - and their mentality is not entirely misguided.

You could throw the same argument at the MediaGoblin people for just using Pump and not using any other protocol - that doesn't necessarily invalidate their desire to put a working federated web together across multiple platforms. They're just following what they believe to be the best way forward.

I have mused on the possibility of writing federation protocol connectors for Hubzilla. I know nothing about it, of course, but I do know that Hubzilla can function as a polyglot for different protocols. If Diaspora, Hubzilla, and Pump all moved to use a specific protocol, we could implement it in the same way that Diaspora federation is implemented, and then figure out how to contribute zot's best bits to an upstream implementation of the spec. Or use Zot as a fallback for Hubzilla users.

Honestly, if we could just get MagicAuth for everyone, that would be truly fucking magical. You could resolve one of the biggest UX problems of interacting with federated content in different places on the web.
  
Well politics in a noble sense is about building a common vision, which helps working together towards a common goal.
  
Sean, you know what you have done in recent years ? you showed interest and not only had  interest, you've tried to understand, you used, you helped, all behaviors which then prompted other people to also have an interest in  #federation, the initial friendicaRED plans  with zot were not the ones to have federation with diaspora, things have evolved because people, devs saw interest from/by other people.

That's what I say, I do not speak technically.

Really people have to put aside the ego, and be more empathetic.
  
from what I see we always need to explain the difference between #federation and #crossposting for new and even old users. Maybe it's better to create a page in the "help" to explain it in the best way.

Often my attempts to explain have failed, perhaps because I explain bad, maybe because people are stubborn, or perhaps for other reasons, so you do not ask me to write this page.

@Redmatrix / Hubzilla Support Channel+
  
Well if you think about it, it isn't "another network", or even another protocol. It's another website. Somehow with all these layers on top of layers on top of layers it's easy to lose sight of that. On usenet, it was multiple newsgroups, on the web, it's multiple urls.

But yeah, 'syndication' might be less confusing, but still imprecise somehow.

Also @thomas is probably right.
  
another reason why cross-posting is actually the same word is because it contains within it the notion of "cross-pollination". Usually on usenet it was used in the negative sense. Like "STOP CROSS-POSTING, they'll find our new group and start posting penis pill spam again!".
However, in the social media age, cross-pollination is considered a good thing.

One major difference though, posting one message to 2 newsgroups was considered cross-posting. Posting a duplicate message to 2 groups, was not. I think this is a semantic protocol difference rather than a human language difference though.
  last edited: Fri, 25 Dec 2015 07:31:51 +0000  
not always negative when not used inapproprately .. . but spammers ruined the party!