In response to Bray’s toot, Evan Prodromou — one of the creators of ActivityPub, who is currently writing an O’Reilly book about the protocol — noted that this “is also the argument for using the ActivityPub API.” He described the API as “an open, extensible API that can handle any kind of activity type — not...
“ActivityPub’s API is how client applications interact with the data on a user’s main account server. It lets the user read data on the same or other servers, and it lets them create activities and other kinds of objects on that server that get shared (under the user’s control) with the rest of the world.”
I can’t see how Apub’s C2S API can realistically be implemented. It’s fairly light on details and if I’m understanding it correctly the only standard way to get activity from the server is to pull from an actor’s inbox, which has to be an OrderedCollection of all the activity the actor has received (likes, notifications, posts, the lot). This shifts a lot of the work to clients which, apart from being being very classist, is very limiting for implementations.
what #mastodon#client do y'all like on #linux? the web-ui is cool and all but it might be neat to have something dedicated. for reference, i am a #husky enjoyer on #android.
"Here's an article and a nice budget, please illustrate it, thanks."
Jobs in the 2020s:
"We're launching a new Gen Y concept in market. It's a fresh approach to Platform X, and we're working with TikTok influencers on unique NFTs. We need you to create 120 generative AI style characters in two weeks. We don't have a high budget, but you'll get lots of exposure. Someone on Fiverr offered to do it for $ 75."
Elk ist ein Fediverse-Client als alternative #Weboberfläche und nutzt die #Mastodon-#Client-#API, um sich mit Konten auf kompatiblen Instanzen zu verbinden.
Nach eigenen Angaben befindet sich Elk im #Alpha-Status. Bugs und fehlenden Funktionen sind zu erwarten.
If there's one thing I'd change about the fediverse (as I understand it), it would be a wider adoption of the ActivityPub client-to-server API. Even more standards!
Colpo di #genio estremamente radicale per risolvere un annoso #problema: il creare una data #webapp, che non abbia bisogno di grande interattibilità (vedi un social network, o un CMS), senza dover mantenere 2 #codebase separate e quindi impazzire, facendola funzionare sia con un #server che totalmente senza… ossia, come unire in una sintesi circa accettabile i due maggiori paradigmi del #frontend? 🤔️
Quello antico, delle prime #piattaforme#web, dove il server genera tutto l’HTML e il browser lo visualizza com’è, spesso con (quasi) zero #JavaScript (vedi la Spacc BBS). 📦️
Quello moderno, dove nel #backend si espongono API (spesso JSON REST), e il fronte viene sviluppato a parte come app che gira totalmente lato #client, con il #browser che richiede pezzetti di dati e fa i suoi iperprocessamenti. 💱️
Ormai quello antico non si usa quasi mai per #progetti nuovi, perché gli svantaggi sono pesanti appena si vuole andare un po’ più in là: per tappare i buchi nel progetto medio si finirebbe a dover scrivere talmente tanto #codice#ClientSide, che a questo punto era meglio fare tutto nel secondo modo, senza menzionare i modelli e le #API da esporre nel server che altrimenti non si sarebbero implementati. Però, le webapp antiche girano bene anche sul computer tascabile meno performante (average Ximi), sui browser vecchi, e spesso sono le uniche che vanno quando tutto il resto ti lascia a piedi. D’altro canto però, anche se in teoria quella #app potrebbe funzionare #offline, magari mostrando dati cachabili, se è sviluppata in modo attaccato al server ecco allora che non si può fare nulla: muore il server, muore tutto. 💣️
Quindi la mia #idea paxxerella, dato che devo fare banalmente una #applicazione come frontend per un altro servizio già esistente, ma voglio i vantaggi appena millantati: sviluppare con i paradigmi #ServerSide in un framework JS adatto, che giri sia in Node che nel browser. A quanto pare, qualcuno ci ha pensato prima, e qualcosa di già fatto ho trovato (Express+FrontExpress, Koa+Koa-Client, Rill)… ma è tutta roba ormai abbandonata, che o non funziona (ho provato) o ha altre #rogne. Te pareva che trovavo mai qualcosa di buono già pronto… Però, in un quarto d’ora ho tirato su uno #script scheletrino, giusto per poter partire per questa via. ☠️
One Login: Towards a Single Fediverse Identity on ActivityPub (thenewstack.io)
In response to Bray’s toot, Evan Prodromou — one of the creators of ActivityPub, who is currently writing an O’Reilly book about the protocol — noted that this “is also the argument for using the ActivityPub API.” He described the API as “an open, extensible API that can handle any kind of activity type — not...