A reasonable ActivityPub / ActivityStreams API to schedule something to be posted in the future might be — to HTTP POST something to an account's outbox with the `published` field set to a date-time in the future.
Recent searches
Search options
#fedidevs
3 posts1 participant0 posts today
Currently, the way I am determining if content is valid ActivityPub / ActivityStreams content is —
№1:
Determining if it is valid JSON.
№2:
Checking if it has a "type" field.
And that is it.
Dealing with JSON-LD would be easier in many ways if everything was defined inline.
Rather than having to get the content from a URL in the context, parse it, etc.
The ActivityPub specification does not have an example of the "sharedInbox" field in use.
Although it does say "An optional endpoint..." — I suspect a lot of people won't know (with confidence) that it can go under the "endpoints" field. For example:
"endpoints": {
"sharedInbox": "https://social.example/inbox"
},
Especially if the person is still trying to understand ActivityPub, and isn't aware of the "endpoints" field yet.
"Activities addressed to this special [public address] URI shall be accessible to all users, without authentication."
https://www.w3.org/TR/activitypub/#public-addressing
The "public address" is:
https://www.w3.org/ns/activitystreams#Public
(Yes, I am posting this for a reason.)
Continued thread
2/
I think there is a need for a "dumb" document format.
HTML is no longer that.
Markdown probably isn't it.
No one really uses enriched-text (IETF RFC 1896).
(I prefer wiki like formats, for various reasons, but —)
I don't think there is an obvious choice for a "dumb" document format, right now.
1/
I think HTML being the default content type for ActivityPub / ActivityStreams is unfortunate in some ways.
HTML was originally a "dumb" document format. But, it is now a "smart" application format — with privacy & security concerns.
https://mastodon.social/@reiver/108237663610634862
You should NOT just take whatever HTML is in the 'content', and put it in the web-browser to view it.
You have to sanitize it. Or, render (unsafe) HTML to (safe) HTML.
Mastodon@reiver ⊼ (Charles) :batman: (@reiver@mastodon.social)1/
I kind of get the feeling that people are trying to refactor the web, in a sense.
And that there are at least 2 different visions for the future of the Web.
Some seem to want the Web to go back to being about (relatively “dumb”) hypertext document format.
Others seem to want the Web to be about a (relatively “smart”) cross-platform application platform.
(There are other visions for the future of the Web too.)
Previews in ActivityPub / ActivityStreams is what should bind the disparate software and user-experiences on the Fediverse.
Not the ActivityStreams 'Note'.
...
Previews using 'icon', 'image', 'name', 'summary', etc.
Continued thread
3/
I think it would be better for the Fediverse if back-end servers and front-end clients were not only decoupled, but separate projects.
https://mastodon.social/@reiver/111030466318220760
https://mastodon.social/@reiver/111223320383410948
https://mastodon.social/@reiver/112746651794313514
https://mastodon.social/@reiver/112921051726027193
People being able to have a service acting on their behalf as (at least part of) the back-end could be a path towards this back-end / front-end decoupling and separation.
Mastodon@reiver ⊼ (Charles) :batman: (@reiver@mastodon.social)For Fediverse software —
In some ways, you could think about Fediverse front-ends and Fediverse back-ends separately.
This is easiest to see if you consider web front-ends versus mobile front-ends.
But you also see this with front-ends within the same class.
For example — Elk is an alternative web front-end to Mastodon's web front-end.
...
If there was a defacto common API for the front-ends to use — you could swap back-ends based on your needs.
Mastodon API may become that.
#Fediverse
Continued thread
2/
In fact, it is an old idea. I remember ideas like this floating around in the 1990s. Including in the P2P scene.
(It is common for ideas to get rediscovered over and over and over again. Different people trying to solve similar problems, and independently coming up with similar solutions.)
1/
In many ways, I like the basic idea of ActivityPods, Bluesky PDS, Account Abstraction.
https://mastodon.social/@reiver/114216978158867263
A service acting on your behalf, and in many ways representing you (the user), with other software.
And something to which data gets "attached".
Mastodon@reiver ⊼ (Charles) :batman: (@reiver@mastodon.social)Content warning: programming
Continued thread
Continued thread
Federated Badges! Very early stages but cool to see new ideas outside of a social media timelines.
#Fediverse #FediDevs #ActivityPub
https://badges.vocalcat.com/record/20
badges.vocalcat.comFediverse Early Adopter of a Decentralized Badge System was issued by Fediverse to Jeff SikesThis badge recognizes the recipient as an early adopter of decentralized badge systems within the Fediverse. By embracing open, federated technologies, they have contributed to the growth of verifiable, community-driven recognition across decentralized platforms.
What about the Fediverse or Mastodon, etc, frustrates you or confuses you?
Do something nice and drop a star on Owncast’s GitHub repository. More stars, more credits.
#FediDevs #Fediverse #ActivityPub
https://fosstodon.org/@owncast/114083484919105292
FosstodonOwncast (@owncast@fosstodon.org)Excited to share that DigitalOcean is now sponsoring Owncast's infrastructure via credits on their platform. https://www.digitalocean.com/open-source/credits-for-projects
They decide who to sponsor, and how much credit to give them, by how many stars the project's repository has. So it turns out a star does have value, after all. So if you have a chance drop Owncast a star on GitHub. It could increase our available credits with them when renewing the sponsorship in the future.
https://github.com/owncast/owncast
Huge thanks to DigitalOcean!
Fun! I like this style of these live streams, more casual and more focused on the person rather than just the code. Check it out.
