*Add: all #viber and #fiverr products are also affiliated with Israel #VoIP #messenger #services

#palestine #genocide

The #fediverse-we-have is predominantly #AppCentric, and that rigid perspective is limiting the promise and potential of the #ActivityPub#SocialWeb protocol.

What would it mean to offer #services on the fediverse, that people can discover, obtain and compose into solutions that satisfy their #social networking needs?

By focusing more on the #ServiceOriented message exchange #architecture, the future fediverse can be one of versatile and interoperable Apps & Services.

#SX

One thing that really pisses me off personally is the #regression in terms of #Messenger#Apps.

My personal distaste and dislike for #proprietary, #SingleVendor & #SingleProvider #services like #Signal¹, #Telegram, #Discord², #WhatsApp, #Slack, #MicrosoftTeams, etc. aside:

• WHY is there no #CrossProvider#Messenger to handle that shite?

• WHY does everyone of these shitty providers think people want to download their #bloated#WebApp that takes up triple digit Megabytes if not entire Gigabytes and will gobble up all the #RAM and #CPU they can??

This problem ain't new and already got solved for corporate social media ages ago! (Not to mention actually good messengers!)

• And no, bridgesdon't count!

• I mean API 0 - style access because obviously none of the platforms will allow, endorse or support such an endeavour and actively fight the developers and users !

So yeah, consider this a call for a @gajim / #Gajim or @pidgin / #Pidginfor garbage platforms!

• Cuz back in the day we had way worse messengers yet people actually made #AIM, #ICQ, #MSN, #QQ, #IRC & #XMPP work just fine from one single "phat" client!

• Can we please get that back?

#api0#Enshittification

One thing that really pisses me off personally is the #regression in terms of #Messenger#Apps.

My personal distaste and dislike for #proprietary, #SingleVendor & #SingleProvider #services like #Signal¹, #Telegram, #Discord², #WhatsApp, #Slack, #MicrosoftTeams, etc. aside:

• WHY is there no #CrossProvider#Messenger to handle that shite?

• WHY does everyone of these shitty providers think people want to download their #bloated#WebApp that takes up triple digit Megabytes if not entire Gigabytes and will gobble up all the #RAM and #CPU they can??

This problem ain't new and already got solved for corporate social media ages ago! (Not to mention actually good messengers!)

• And no, bridgesdon't count!

• I mean API 0 - style access because obviously none of the platforms will allow, endorse or support such an endeavour and actively fight the developers and users !

So yeah, consider this a call for a @gajim / #Gajim or @pidgin / #Pidginfor garbage platforms!

• Cuz back in the day we had way worse messengers yet people actually made #AIM, #ICQ, #MSN, #QQ, #IRC & #XMPP work just fine from one single "phat" client!

• Can we please get that back?

#api0#Enshittification

"Public services are inefficient"
Nope, neoliberalism fools us by dismantling public good, and blame it after. "Break it, blame it, sell it".
#neoliberalism #publicgood #services #publicservice #publicsystems

"Public services are inefficient"
Nope, neoliberalism fools us by dismantling public good, and blame it after. "Break it, blame it, sell it".
#neoliberalism #publicgood #services #publicservice #publicsystems

Day by day, service by service we can detach ourselves from the underlord grips.

TIL that I dont need google anymore for reliable avg exchange rate values of currency

#OpenSource#Alphabet#Google#Android#Services #programming #currency#exchangeRate#EUR#SRD

Now that #swad 0.7 is released, it's time to prepare a new release of #poser, my own lib supporting #services on #POSIX systems, following a #reactor with #threadpool design.

During development of swad, I moved poser from using strictly only POSIX APIs (with the scalability limits of e.g. #select) to auto-detected support for #kqueue, #epoll, #eventports, #signalfd and #timerfd (so now it could, in theory(!), "compete" with e.g. libevent). I also fixed quite some hidden bugs, and added more base functionality, like a #dictionary using nested hashtables internally, or #async tasks mimicking the async/await pattern known from e.g, #csharp. I also deprecated two features, the periodic and global "service tick" (superseded by individual timers) and the "resolve hosts" property of a "connection" (superseded by a separate resolve class).

I'll have to decide on a few things, e.g. whether I'll remove the deprecated stuff immediately and bump the major version of the "posercore" lib. I guess I'll do just that. I'd also like to add all the web-specific stuff (http 1.0/1.1 server) that's currently part of the swad code as a "poserweb" lib. This would get a major version of 0, indicating a generally unstable API/ABI as of now....

And then, I'd have to decide where certain utility classes belong to. The rate limiter is probably useful for things other than web, so it should probably go to core. What about url encoding/decoding, for example? 🤔

Stay tuned, something will come here, maybe helping you to write a nice service in plain #C 😎:

https://github.com/Zirias/poser

From an idea to a working beta version in just a few hours. #IPv6 tunnel service with #Wireguard and #OpenVPN support. GRE & SIT follows, OpenVPN PKI backend will be switched to Hashicorp Vault.

Still several things to do… #network#IPv4#GRE#SIT#Tunnel #homelab #net #services @BoxyBSD