Recent searches
Search options
Administered by:
In addition to turning off their API, #Twitter has also inexplicably turned off access for users to sign in to Flipboard and other platforms with Twitter SSO.
This is an unacceptable breach of trust between Twitter and their developers and users. Twitter must be held to account here.
As you know, this goes on, and on, and on with platforms that assume they control a monopoly.
The only way to avert these disasters is via proper exploitation of loose-coupling that's been delivered on a platter by the #Web.
Right now, I am a little concerned about #Mastodon #API overshadowing the #ActivityPub protocol re loose-coupling of clients and severs across the #Fediverse.
Most think this is okay, but we've seen this movie before++
Yep.
Open protocols are the ultimate protection against inevitable compromise.
Only implementing a part of the #ActivityPub protocol weakens the #Fediverse as an open #SocialMedia collective comprising loosely-coupled clients and servers.
/cc @Mastodon
@kidehen I agree with you. [edited]
It's not sustainable to build a new social graph around every type of experience.
We should have apps that create activities that go into one social graph, and that draw on that one social graph.
@mike you should keep building on the API. I think it's the right move.
Eventually we'll have a more standard API, the ActivityPub client API, and you can use that standard one or the Mastodon one or both.
Again, how is it that you don't glean the quest for a client-server implementation of the #ActivityPub protocol from my comments?
The server-server implementation by @Mastodon only addresses part of the problem re loose-coupling of clients and servers across the #Fediverse.
BTW -- This situation is very similar to #Email where even hosted services like #GMAIL support #IMAP4 and #POP3 rather than just #SMTP .
I hope my position is clearer now?
/cc @mike
@evan @kidehen @mike Credit where credit is due as well - making ActivityStreams an RDF vocabulary was a really great idea that allows the social graph to represent objects/concepts/etc. which nobody contemplated when it was made.
The trouble is, as with all great RDF things, getting people to parse it as RDF and not its serialization format (JSON-LD here) so they aren’t broken by novel but conformant uses of ActivityPub/ActivityStreams.
@evan @kidehen @mike (also I realize you don’t need your own thing explained, but I didn’t want to leave context out for anyone browsing the thread who might not know what “creator of GNU Social” means, and “RDF was an excellent choice” on its own is confusing to anyone who isn’t familiar with the underpinnings :))
I don't know whose idea it was to make AS2 based on JSON-LD. Definitely not mine; I assume James Snell's.
If I remember correctly, it was already assumed by the time we started the WG. We may have had some conversation about it during the group meetings.
I think @jasnell had done a draft of AS2 previously as an RFC for IETF maybe? It may have been JSON-LD back then.
@evan @ZiggyTheHamster yeah that was me. The original ietf version was not JSON-LD, but it was switched quickly after a few discussions around it. It adds complexity, yes, but also a great deal of processing flexibility. It was critical that we also maintained that "It's just json" feel to it tho, which is why we constrained the serialization.
@evan @mike @kidehen fwiw pleroma implements C2S in case anyone wants to try it out.
also: this is the issue for implementing that on mastodon https://github.com/mastodon/mastodon/issues/10520
I haven't said anything about "every type of experience" so I don't understand how you've drawn that conclusion.
A little more confusing is the fact that you say "Eventually we'll have a more standard API, the ActivityPub client API, and you can use that standard one or the Mastodon one or both." which is my fundamental point.
I explicitly said:
Options are better for the #Fediverse than a product-specific #API re loose-coupling of clients and servers.
What did I miss?
/cc @mike
I didn't say or insinuate that. I was simply expressing concern about the server-server centricity of @Mastodon in relation to its #ActivityPub support.
Simplest example is #Email where #SMTP plays the role of #ActivityPub re moving #mbox docs across outboxes and inboxes; with #IMAP4 (a client-server protocol) handling retrieval.
Even #GMAIL supports #IMAP4 (and #POP3) while also having its own #API.
@Mastodon should operate in similar fashion is my point 
/cc @mike
Good thing that's come out of this conversation is the emergence of a comparative stack for those unfamiliar the general pattern for interacting with inboxes and outboxes unleashed via #email.
#GMAIL is the hosted equivalent of @Mastodon.
#SMTP is the server-server protocol for delivering #mbox docs to inboxes and outboxes.
#IMAP4 is the client-server protocol (implemented by GMAIL but missing from Mastodon).
#ActivityStreams is the mbox payload equivalent.
@evan @kidehen If you mean a pubic API façade for the Mastodon API, that may be impossible. Mastodon has an #ActivityPub inbox endpoint, but it does not have an Activity inbox per se (the received activities are not stored, just applied to the Mastodon data store).
I would be interested in the opposite direction (and possible). So we have an ActivityPub C2S endpoint, and convert it to Mastodon.
This is probably still hard, but should be possible by adapting any existing software supporting the Mastodon API + ActivityPub. The hard stuff is: Who gets to manage the ids?
@helge why do this?
@steve @kidehen yeah, I haven't looked closely enough at the Mastodon API to say for sure.
But you can do some reverse engineering.
If you have a stream of objects, each of those has a Create activity.
Edited items can get an Edit activity.
A collection of likers can be interpreted into Like activities.
IDs will be incorrect or missing. Dates will be wrong or missing.
It's imperfect but façades always are.
@bhaugen @evan @mike Imagine if #GMAIL only offered an #API without support for #IMAP4. The tradeoffs would be quite negative i.e., no additional experimentation required.
Every modern #email app supports #IMAP4 for interacting with inboxes and outboxes managed by a mail server.
Email is a generic function. Sociality via a #Fediverse should be similar. All that's required is support for the client-server aspect of the existing #ActivityPub spec