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?
They are 3 different protocols that don't inter-operate. Though some software can communicate with 2 or more. Mastodon for example falls back to OStatus if ActivityPub does not work.
And so in that sense, to respond to your question, ActivityPub completely replaces OStatus.
OStatus is a decentralized social networking protocol which - as you say - is made up of several other protocols: Atom feeds, Activity Streams (version 1.0), PubSubHubbub, Salmon, and WebFinger.
It is still used by Friendica and GNU Social (formerly StatusNet).
It is no longer used by Mastodon. Support was removed in 2019 in favor of ActivityPub.
pump.io is an engine with an API that exposes Activity Streams (version 1.0). Pump.io was meant as a successor to StatusNet.
Identi.ca switched from StatusNet to pump.io in 2013.
Pump.io intends to deprecate their API and move to ActivityPub (see Developer docs).
Activity Streams is for the serialization of a stream of social activities using the JSON(-LD) format.
Version 1.0 was created by a working group that had Google, Facebook and Microsoft backing. It uses JSON as serialization format.
Version 2.0 was a sanitized version derived from 1.0 and uses JSON-LD as serialization format. It has become a W3C Recommendation that comes in two parts: Core and Vocabulary.
ActivityPub is a decentralized social networking protocol that is based upon Activity Streams 2.0 and it is the basis of the Fediverse. It is also a W3C Recommendation.
The ActivityPub specification is intentionally incomplete and flexible in a number of places. In order to create full-blown fediverse apps it should be combined with:
Webfinger (to find federated accounts)
HTTP- and/or JSON-LD Signatures (for server-2-server communication)
OAuth 2.0 (client credentials, authorization scopes).
For a long and ever-growing list of ActivityPub applications see the Feneas ActivityPub Watchlist.
So in summary OStatus, pump.io API and ActivityPub are three separate incompatible means to create federated social applications (that have nonetheless some common denominators). Of these ActivityPub offers the best way forward, and is the protocol you should choose from this list going forward.
PS. The best places to ask questions as an ActivityPub implementer are the SocialHub and Feneas forums. And see also the Guide for new ActivityPub implementers at SocialHub.
Related
I understand that PKCS#11 is std that defines cryptoki API and KMIP is a protocol that defines message format, but how they are connected or are they even interconnected?
How they both hold their individual significance in cryptography?
PKCS#11 can be considered a protocol of a kind too, it's used to communicate with the hardware devices (to be precise, with the driver modules of those devices). However, it's not suitable for network communications. KMIP is the protocol to communicate with remote key storages and similar services and use the remotely stored keys. This is similar to what PKCS#11 offers locally.
In theory, the protocols partially interlap and are to certain extent interchangeable - Oracle has the PKCS#11 driver/gateway, which talks to the remote KMIP server, and the opposite should also be possible. But, of course, each has its own strengths and weaknesses. Interestingly, both KMIP and PKCS#11 standards are developed by the same people in OASIS.
There's also a paragraph in Wikipedia that answers your question.
Telegram is a cloud based chat service. All of their clients are open source. I was wondering if there's a way to host a 'private' telegram service on my own server.
If not, is there anything out there that can provide all or almost all features that telegram provides?
According to the official telegram FAQ the current answer is no:
Q: Can I run Telegram using my own server?
Our architecture does not support federation yet. Telegram is a unified cloud service, so creating forks where two users might end up on two different Telegram clouds is unacceptable. To enable you to run your own Telegram server while retaining both speed and security is a task in itself. At the moment, we are undecided on whether or not Telegram should go in this direction.
So as long as the server itself is not open-source the entire Telegram eco-system cannot be considered open-source, even though there is an open API and official open-source clients.
There seem to be some unofficial telegram servers, but it's not clear how compatible they are with existing clients.
Some possible telegram alternatives
Matrix is allegedly providing "an open network for secure, decentralized communication" and has both open-source clients (Element being the 'official' one) and an open-source server that can be self-hosted. BUT while it looks good on the surface, there are indications that companies behind it have undisclosed intimate links with governmental actors (similar to Signal).
XMPP/Jabber has been around for a longer time, is an open protocol with multiple server and client implementations, and might be the least tainted by third-party interests. XMPP was the underlying protocol behind the original Google Talk messenger before it was rebranded to Google Hangouts and switched to a proprietary protocol.
Teamspeak a collaborative platform for teams, intended originally for gamers, free client and server.
Mumble a voice oriented solution which allows self-hosted servers.
You could implement a full working Telegram-API, then have hosted clients on your server via this API.
Your users would login on your web, then you sign them in via the hosted clients on your servers.
You are basically performing a proxy service to these users , and you can even integrate other value added features for you users this way.
Hi went through Enterprise Integration Patterns by Gregor Hohpe and Bobby Woolf.
http://www.eaipatterns.com/toc.html
I also went through Camel and Mule's compliance with these integration patterns -
http://www.mulesoft.org/documentation/display/current/Understanding+Enterprise+Integration+Patterns+Using+Mule
http://camel.apache.org/enterprise-integration-patterns.html
I see that both Mule and Camel allow applications to be deployed and accessed via webservices like SOAP or REST, SOAP being more RPC style. They allow massive integration support using opensource utilities like CXF and Jersey. In fact Mule also supports RMI endpoints - which will give remote method invokation capability as well which is a well-accepted form of Integration.
I understands ESBs are built around a Message Bus with additional support for other protocols however ESBs only comply to EIP and EIP is not just ESBs.
Question is why SOAP/REST or their transport protocol not considered as "Integration Styles" and which is Enterprise Integration so "Message Oriented"?
I am a novice compared to the great minds which designed these patterns but trying to understand the lopsided message-y nature of Integration patterns. I admit it isn't quite the QnA format of stack overflow but will request Mods to keep it alive for a while so that people can share their opinions.
As for SOAP, it would put it under the Integration Style "Remote Procedure Invocation", since it's pretty much what SOAP implements in reality (I won't consider the SOAP over JMS hybrids here with a potential to mix RPC with Messaging..).
REST is, interface wise, very different from SOAP in that it's resource driven instead of service driven. I would non the less group it under the "RPC" style since it's just another format of syncrhonous RPC calls.
I would, however, not put too much effort in theory of what EIP integration style a specific message pattern implements.
Look at a specific scenario at hands instead and use the EIP to model your specific integration.
I've seen integrations of file transfers that in realtiy implemented RPC patterns or SOAP services that in reality implemented messaging (although I don't really recommend do this).
A concrete example: consider the usage of a dedicated file upload service, which happends to be built using SOAP technolgy, which uploads a CSV file to a file area on a server, from where it's picked up by some other system. I would call this file based integration on a high level.
Another example is that Messaging systems sometimes are implemented using a shared database. Still the integration style using them is messaging, not "Shared Database".
Think about how your integration should work on a high level, then apply the various protocols to do the grunt work.
I was working on Java Agent Development Framework, which is the language of creating mobile agents. I was wondering that the code that I will write in JADE, will work over HTTP or below the HTTP? As I am opaque to the inside working and execution of JADE I couldn't get the answer directly...Thanks in advance :-)
JADE (or more generally FIPA standard) introduces the concept of platform consisting of one or more containers on which agents live. Each container is made up by a separate JVM. JADE distinguishes between two types of communication, depending on where the talking agents live:
intra-platform communication, when messages are exchanged between agents living on different containers of the same plaform
inter-platform communication, when messages are exchanged between agents living in different platforms
Depending on where the talking agents live, different protocol will be used.
For intra-platform communication one of the following transport protocols will be used:
RMI (default), going directly over TCP/IP
proprietary protocol based on TCP sockets (used in J2ME environment in JADE LEAP platform)
For inter-platform communication one of the following transport protocols will be used:
IIOP (Sun or ORBacus implementation)
HTTP and HTTPS
JMS
Jabber XMPP
Since the question is specific to JADE platform, I strongly encourage you to use JADE mailing list: http://jade.tilab.com/newuser.php
NServiceBus and MassTransit are two tools that can be used to implement messaging with MSMQ and other message queues.
I find that once you start using messaging to have applications talk to each other, you don't really want to go back to the old RPC style.
My question is, what other tools are out there? What tools do you use?
Apache ActiveMQ is probably the most popular and powerful open source message broker out there with the most active open source community behind it as well as commercial support, training and tooling if you need it.
One of the more interesting aspects of ActiveMQ is its wide support for a large number of different language bindings and transport protocols
WebSphere Message Broker is IBM's flagship ESB which runs ontop of MQ.
They also produce WebSphere ESB which is a slightly lighter offering which specialises in ESB across web services.
We use WCF services for synchronous message based operations, and nServiceBus for anything asynchronous.
Rogue Wave is very popular [ http://roguewave.com/products/hydra/ ]
So are IBM's Websphere offerings [ http://en.wikipedia.org/wiki/Mqseries ]
WCF is extremely powerful and should be looked into by anyone in the .NET space starting up a message based system.
I would recommend against BizTalk unless you can make a lot of use out of it's adapters (ie. you have a lot of old systems to communicate with).
Nuedesic makes a great WCF based ESB, Neuron, if you are willing to pay a bit.
I use IBM software stack because it has the widest set of features (pub/sub, async, sync) and platform support (60+ combination of platform, languages) and also a great set of free tools provided by IBM
For Operations, I use use the linear log rotation IBM WebSphere MQ supportpac
For development and testing, I like RFHUTIL to generate fake cobol, java, MS objects, other binary and text objects and SOAPUI to invoke HTTP web services. If I need to invoke MQ based web services, I go back to RFHUtil. Of course Websphere MQ Explorer for admin.
We use the old WebSphere Message Broker 6.1 (now IBM Integration Bus) that is fast and reliable once you are acquainted.