https://pixelfed.org/

A service very much like Instagram, but federated. There seems to be quite some enthusiasm around ActivityPub-based projects in general, also including Prismo, Anfora and Funkwhale.

playSMS

A flexible Web-based mobile portal system that it can be made to fit to various services such as an SMS gateway, bulk SMS provider, personal messaging system, corporate and group communication tools

There’s a maintained Dockerfile already.

Feature Highlights (brace yourself!)

• Multiple database engine supported (through PHP PEAR DB, included in this package)
• Send SMS to single mobile phone
• Send SMS broadcasted to a group of mobile phones, or SMS bulk
• Support sending text, flash and unicode messages
• Capable of handling large amount of SMS
• Receive private SMS to Inbox and forward it to email (mobile2web) and user’s mobile phone
• Forward single SMS from mobile to a group of mobile phones
• Provides SMS to email and email to SMS by polling mailbox
• SMS autoreply, for easy autoreplying formatted incoming SMS
• SMS board, forward received SMS to email, export output in JSON and a few other formats
• SMS command, execute server side shell script using SMS
• SMS custom, forward incoming SMS to custom apps, locally or hosted on external URL
• SMS poll, manage polling system using SMS, export output in graph, JSON and other formats
• SMS quiz, serve quizzes on SMS
• SMS subscribe, manage user subscribes to a service using SMS
• SMS sync to utilize SMSSync app
• Blacklist, stoplist and firewall plugin for SMS services protections
• Create your own features, tools, themes and gateway modules as a plugin
• Supports software gateway such as Gammu, Jasmin, Kannel and SMS Server Tools 3
• Supports bulk SMS providers such as Nexmo, Twilio and other SMS service providers
• Supports many other bulk SMS providers using Generic gateway plugin
• Supports sending/receiving SMS via another playSMS using Planet or Uplink gateway plugin
• Supports simulation gateway for testing incoming and outgoing SMS
• Supports multiple active SMSC
• Route outgoing SMS by prefix
• Route outgoing SMS per user
• Webservices for sending SMS, retrieving delivery reports, checking credits and more
• Long SMS support, length of text is configurable
• Rate SMS by destination prefix
• SMS credit system per user
• Multiple SMSC activated and routable
• Timezone settings
• Multi-language user interface (English, French, Bahasa Indonesia, Russian and a few others)
• Easily add new language for user interface
• Web-based interface
• Android app for playSMS is available, with source codes
• Multi-domain from single playSMS installation with site branding for reseller supports

As described here I expressed an interest in a Jitsi Meet app but I wasn't in a hurry.

Now I really need it. The pandemic is causing serious problems throughout the world and some centralized systems are getting really strained as everyone in self-isolation or quarantine moves to video conferencing.

Now would be an excellent time to push Jitsi Meet out the gates. I need to provide video conferencing solutions to several organizations. Please prioritize this if you can.

In my profession I’ve recently been assimilated into the Notion universe. It’s truly brilliant.

But it’s not free (as in freedom). So as I start to pour huge amount of work into structuring and using it, my woes of lock-in comes as expected.

There’s this whole new class of digital tools flexible enough to be shaped by non-coders for virtually any workflow: Notion, Airtable, Coda, Next Matter.

I sense that as the tools of this no-code movement develops further, users realize they don’t need to settle for other people’s workflow but can shape the tools to their liking instead of the other way around. Thus these tools may lay the groundwork for a new level of user expectancy, possibly leaving old rigid tools in the dust.

So, is there anything FOSS that can even begin to compare to Notion?

Reading this makes me grateful that Cloudron exists. @nebulon and @girish should really take pride in what you’ve built. Not only in the software itself but the community around it, that’s very much influenced by the attention and sensitivity you guys nurture it with.

In Sweden, online conferencing has increased 500% over the last week. Properly configured selfhosted Jitsi servers could play an important role for these usecases and for months and months to come.

That feeling when something you’ve wanted for years finally realizes.

Wireguard 1.0.0 is now audited, released and included in the Linux 5.6. Time to get the app going!

I've written about this issue in various topics where related but now want to distill those thoughts in a dedicated one.

Federated services?

Various services that are federated in one way or another typically serve from the root domain. A few examples:

• Matrix, a popular federated chat service. (1 587 public servers with ∞ users)
• Mastodon, a very popular federated microblog service. (2 744 public servers with 2 270 595 users)
• PeerTube, a somewhat popular federated video streaming service with peer-to-peer content distribution. (340 public servers with 23 164 users)
• PixelFed, an emerging federated Instagram-like image service. (107 public servers with 15 966 users)
• WriteFreely, an emerging federated blogging platform. (199 public servers with 5 490 users)
• IRC, a well established chat service. (∞ public servers with ∞ users)
• Email (∞ servers with ∞ users)

Problem

Regardless of what subdomain these services are served from technically, they all require some routing via the root domain to work properly. Sure, some can be served from a subdomain but it's bad practice.

In Cloudron, support for this type of routing is currently absent except for email (which is obviously because it makes up such a central component of the Cloudron system). The routing required for federated services typically means forwarding a port or two towards the true location of the service.

Proposal

The solution I imagine is that apps requiring this routing registers extra ports in their app manifests that then targets the root domain, which should still be open to serve a completely different app on that location as well. Just like email works right now alongside whatever is installed on the root domain.

Now, if Cloudron were to accomodate for this type of root domain routing then the system would be quite ideal for hosting not only the typical web apps already possible, but the whole plethora of emerging federated services as well. The numbers shows a pretty good interest in these types of services.

Let's hear it

I'd hereby like to initiate a solution oriented discussion on this topic. I would especially appreciate the views of @girish and @nebulon, but of course community members like @msbt, @murgero, @kasini and @october as well.

This is a great day to be a cloudronite

I like this initiative!

I’m focused on design and ops, but I’m low on availability currently.

Selfhosting the repo isn’t the solution it may look like though. What moving off Github really entails is increasing the effort of contributing to the project as coordination capability and discoverability tanks.

This is the stranglehold the centralized services always have. A way to circumvent that is to federate Github-like services, a strategy in which Cloudron really can play a part.

The projects aren’t there yet but there’s coordination happening between existing selfhosted git collaboration platforms such as Gitlab and Gitea, and on the Web3 side of things Radicle is moving into beta soon iirc.

Oh, it did change. Nevermind ¯_(ツ)_/¯

Note that in comparison with typical social media reputation score is a thing on NodeBB. I feel like the voting system is used in a very positive and encouraging way in this community as well, I’m actually inspired to replicate it in other communities.

On occasion downvotes happen. In my experience it’s usually not when members disagree on taste or favorite apps but when the content is outright spammy, abusive or utterly negative. Then the community reacts and rightfully so.

I see no issue with the current system at all and I see no point in changing what has been around and worked well for so long.

I like the current system. It’s a good balance between a little insight into who upvoted while at the same time pivots towards being the ”community voice” by avoiding personal grudges by hiding occasional downvotes. Qualitative responses is best expressed in replies anyway, imo.

@girish And meanwhile if I want to go venture off with a forked Discourse app with the only difference being that the LDAP addon is added, I should be able to stay compatible with the official one within foreseeable future, right?

Nice, I like it.

@mehdi Yes, @malvim deserves huge credit for this effort.

Nice! It will be highly interesting when/if we get Cloudron working on the ARM architecture.

Bounty is being raised to $1000: https://github.com/alextselegidis/easyappointments/issues/209#issuecomment-704054149