It was wise of @drewdevault to host redict (redis fork) on @Codeberg to maintain workflow parity with github and avoid any perceived conflicts of interest¹.
I wondered why LGPL and not of AGPL², which is also explained nicely: "but we want to make it as easy as possible for users to comply with the Redict license and we do not see any reason to discourage cloud providers from making use of Redict."
@shom@immibis@Codeberg moreover, it is a stronger political rejection of RedisLab's re-licensing move if the license of Redict does not eliminate any use-cases, such that it can quickly and effectively make the now-proprietary upstream software irrelevant.
@drewdevault @immibis@Codeberg to add to that: drop-in replacement isn't just technical, it's also license. This makes redict a true drop-in replacement.
If I drop a shortcut/file on to my desktop at position x, y --- and position x, y is an empty space with no conflicts with other shortcuts... THAT is where it should land & stick.
No - I do not have auto-format on.
AND why would you move it to a place that shifts my other "organized" shortcuts.
@Kevin20221110 Blocking a spammer is good, if that's the source> They only use that xueksda account name once, but auto-generate 100 more and the Admin is likely the originator. So reporting does nothing. This is a new Spam, not someone sharing their new book or album, it's pages of Japanese spam, sent by multi-accounts from multiple new instances of less than 100 members, many without faces or readable names. It's a SPAM factory we are dealing with
Turns out #Gitea was turned into a for-profit company two years ago. The software remains MIT-licensed, but it's now centered around enterprise solutions
However Gitea's community was not happy about this and created a soft fork that remains fully-compatible, community-driven. It's called #Forgejo and #Codeberg switched to using it in favor of Gitea.
"A John Cage piece for organ titled ASLSP - as slow as possible - lives up to its name. It has been in performance for 21 years so far...
[The John Cage Organ Foundation] decided the piece would be played for 639 years to mark the time between the construction of the world's first 12-tone gothic organ in Halberstadt in 1361 and the new millennium"
I've written an ActivityPub server which . That's all it does. It won't record favourites or reposts. There's no support for following other accounts or receiving replies. It cannot delete or update posts nor can it verify signatures. It doesn't have a database or any storage beyond flat files.
But it will happily send messages and allow itself to be followed.
This shows that it is totally possible to broadcast fully-featured ActivityPub messages to the Fediverse with minimal coding skills and modest resources.
I wanted to create a service a bit like FourSquare. For this, I needed an ActivityPub server which allows posting geotagged locations to the Fediverse.
I didn't want to install a fully-featured server with lots of complex parts. So I (foolishly) decided to write my own. I had a lot of trouble with HTTP Signatures. Because they are cursed and I cannot read documentation. But mostly the cursed thing.
Creating a minimum viable Mastodon instance can be done with half a dozen static files. That gets you an account that people can see. They can't follow it or receive any posts though.
I wanted to use PHP to build an interactive server. PHP is supported everywhere and is simple to deploy. Luckily, Robb Knight has written an excellent tutorial, so I ripped off his code and rewrote it for Symfony.
The structure is relatively straightforward.
/.well-known/webfinger is a static file which gives information about where to find details of the account.
/[username] is a static file which has the user's metadata, public key, and links to avatar images.
/following and /followers are also static files which say how many users are being followed / are following.
/posts/[GUID] a directory with JSON files saved to disk - each ones contains the published ActivityPub note.
/photos/ is a directory with any uploaded media in it.
/outbox is a list of all the posts which have been published.
/inbox is an external API endpoint. An ActivityPub server sends it a follow request, the endpoint then POSTs a cryptographically signed Accept message to the follower's inbox. The follower's inbox address is saved to disk.
/logs is a listing of all the messages received by the inbox.
/new is a password protected page which lets you write a message. This is then sent to...
/send is an internal API endpoint. It constructs an ActivityPub note, with attached location metadata, and POSTs it to each follower's inbox with a cryptographic signature.
That's it.
The front-end grabs my phone's geolocation and shows the 25 nearest places within 100 metres. One click and the page posts to the /send endpoint which then publishes a message saying I'm checked in. It is also possible to attach to the post a short message and a single photo with alt text.
There's no database. Posts are saved as JSON documents. Images are uploaded to a directory. It is single-user, so there is no account management.
I've raised an issue on Mastodon to see if they can support showing locations in posts. Hopefully, one day, they'll allow adding locations and then I can shut this down.
The code needs tidying up - it is very much a scratch-my-own-itch development. Probably riddled with bugs and security holes.
@mat@blaine
I think it is a bit like Postel's Law. Servers will happily receive anything - but they will only send out what they understand or deem safe.
For example, I could embed a <script> tag in my content, but most servers will filter that out.
As an admin, I'd be wary about passing on a type, object, or activity that I wasn't 100% sure clients would understand.
So, I agree with you in theory. But I understand why the current practise is different.