An "open letter" to the Session team.

Hello, I've posted here before … As I said in that previous post, I've been waiting for some problems in Session to be addressed before I move to it and ask my friends and family to do the same (a VERY DIFFICULT thing, because ALL of them use Whatsapp and I'm the only one who cares about privacy).

Despite the limitations in Session, a couple of days ago I decided to "initiate" the transition to Session as my main IM app… But, oh, boy… In just 2 days of using it, there are so, so many small issues with the app that I think this app is going to suffer the proverbial "death from a thousand papercuts".

Most things are obvious and "easy to fix"… But that's the point, if in the more than 3 years Session has been out, all these small issues are still present, I'm losing confidence in this project.

1.- Blatant inconsistencies between the Mobile and Desktop experiences. When an application is present in different platforms, is understandable that some things will look and behave slightly differently, but those things SHOULD obey inherent limitations or features of the platform, not just plain oversight or lack of attention.

1.1.- In Desktop I can't send animated GIFs, but in Mobile (Android) I can. This is the least important inconsistency (to me), but it's still something that should be consistent in all platforms. There's just no reason to be present in one platform but not the other.

1.2.- In the Desktop version I can change the playback speed (1x - 1.5x), but I can't in Mobile (Android). Another basic inconsistency that frustrates me a lot! This should be present in all platforms! also, there should be a preference in the settings to automatically play all voice notes at, e.g.: 1.5x. it's incredibly annoying having to click each and every voice note to change its playback speed.

1.3.- Completely different look in playback controls for voice notes in Session Desktop and Mobile (Android). Once again, in some aspects (like your web page and blog) you appear to be very design-oriented and you claim to put a lot of effort in making Session visually appealing, easy to use and all that… Yet, here's a side-by-side screenshots of a voice note conversation I had as seen in Desktop and Android: rect920 There are so many UX flaws in these images (especially in the Android/Mobile side) that I can't understand how you ended up with this mess. (more on that later in this post)

1.4.- In Session Desktop I can record/send voice notes of more than 1 minute but in Mobile (Android) we still have the stupid 1 minute limit. This is the one that pisses me off the most!… I've been waiting 8 months for Session to address the 1-minute limit of voice notes, thinking "oh, they want to be very economic in the bandwith usage to keep the decentralized servers ecosystem in optimal working order"… And now I notice that I can record/send voice notes of 2, 3, 4… minutes from the Desktop Session app but still not in the Mobile version. This snapped me out of the delusion of you being bandwidth concious. I mean, you added voice/video calls! That feature is much more bandwidth hungry than a 5-minute voice note limit, but you still implemented calls… This lack of direction and consistency in the project really pisses me off.

I'm not done… Here's a couple more problems in my 2 days of use!

2.0.-Lack of information when rejecting attachments. https://user-images.githubusercontent.com/13471025/205156041-3f368b6a-b761-46f3-a145-cf4818ad07ac.mp4 In the video, I try to send a file through the options menu inside Session and the file is larger than the size limit, I just get a microscopic, dark red warning icon (I think)… no explanation, no description, no option to at least tap on the microscopic icon with my pinky finger for more info, nothing!… Then, I instead try to send the file/video through the "share" function from an external file browser; that time at least I get a brief text describing the problem…

I shouldn't have to explain how terrible this is. At the very least, that same text should appear in both instances if attaching a file/video; but still, a warning message that disappears 5 seconds later is a no-no!… Ideally, the text should appear next to the microscopic icon (which, for hell's sake, make it bigger!) and stay there. Just like another message in the conversation, but with a clear warning icon and color that the user can read later if they're distracted for more than 5 seconds!

2.1.- Terrible UX in the Mobile UI. This one is mind boggling!… The Desktop version of Session, the one that is controlled with your mouse in a computer… has a better UI design for touch screens than the Mobile version, the one that would benefit from those design choices. I mean, look: https://user-images.githubusercontent.com/13471025/205156890-917a7316-5e72-4ef1-a7e0-d37a3ed5e71d.mp4 In the Desktop version (right) we have much bigger buttons, visual feedback, playback control… In the Mobile version (left) we have a tiny voice note message where you don't have any control besides play/pause. There is a sort of "progress bar" during playback, but you can't interact with it and has so little visual contrast that is almost the same as not being there… Really, mind boggling.

And the final problem in my 2 days of use… You might have noticed this one in my previous image: 2022-12-01_10-41 When I send voice notes of more than 1 minute from my Desktop, in my Mobile they show a weird length, like "1:78", "1:83"… one more to the list of the thousand papercuts.

Sorry for the harsh comments, but the more I write this post, the more frustrated I become!

I've been following this project for almost 2 years, watching all the weekly Youtube videos, podcast interviews, Twitter (and now Mastodon) posts… waiting for the project to grow into a mature app to make the switch from Whatsapp, but seeing the very basics of the app still in such a messy state, is making me question all the time and hopes I have put in Session/OXEN/Lokinet.

This project is so scattered and chaotic in its development priorities… In one instance you spend months working on audio/video calls, a major undertaking and a good reason/excuse to say that such a feature demanded a lot from the developer team and because of this, some smaller features and problems sort of slipped through the cracks… But it's been like 6 months since the initial iteration of the calling feature was added and these other obvious problems, inconsistencies and terrible UX flaws are present. You instead spend weeks developing (and boasting about) f*ck¡ng "Emoji Reactions", the most stupid and least necessary feature you could have thinked of!

I remember Kee Jefferys in one of the weekly videos explaining ID blinding (a great and much needed feature) and right after, dedicating like 4 minutes of the video talking about Emoji Reacts, explaining the challenges of implementing them and I wonder… REALLY? Was this a feature that a lot of users needed and were asking for?… or maybe it was a feature that the Session team capriciously wanted to add?… If you spent so many hours thinking and discussing the implementation of Emoji Reactions, I think you should do the same with all the other, more important things I mention in this post. I'm not asking for crazy, unreasonable things, like 1GB file attachments, an OXEN wallet integration, a "Stories" feature to compete with whatever latest gimmick in other social media and IM apps… I'm asking for things that should have been addressed long ago! I know Session began as a fork of Signal, but it's been more than 3 years! If these issues come from the original Signal source code, you've had plenty of time to address them.

If you've been able to make a very sophisticated, onion-routed, decentralized, multiplatform app like Session (and Lokinet, and the OXEN cryptocurrency, wallet and servers ecosystem), you also have the knowledge and expertise to address such basic inconsistences! And I'm just mentioning the things I've seen in 2 days of use!

Anyway, I hope you see that this rant comes from someone that cares about the project, that wants to see it succeed. English is not my native language, but I still took the time to write and prepare this post. So please, hire a good UX person. The community is good for some reports, but very few have the time or interest in reporting problems in a detailed manner. Hire a couple of beta testers, give them an economic incentive, make it a job. (which, I'd be interested in working as a beta tester, BTW)… But seriously, your messed-up priorities in this project are dragging its adoption!

Is not the big, flashy features what will make Session succeed, is a consistent and smooth user experience what users need. Greets.

Fully agree with both the content and the motivation behind this issue. I have similar challenges in using session that no one seems to want to address.

The recent video about the new direction and goals of session indicates a 3 step approach to development, that is predicated on the user base increasing to a certain size to reach each objective. However the seemingly basic glitches / challenges that never seem to be addressed make it extremely difficult to increase the user base by introducing to friends, family etc. Unless they are addressed I cannot see how the user base will increase to reach said goals.

For the average user they need several basic features that work consistently to accept a new platform. They don't need all the latest bells and whistles, just basic features that work well every time.

**Notifications.

Session promotes its usability in times of upheaval when other messengers are blocked etc, promoting itself as privacy focused. Many privacy minded folks use alternative os's that do not have Google services. There also is a large chunk of the world, for example Ch... and other countries where many Android devices do not have Google services installed. Session has been translated into many of these languages.

If supporting these communities and thereby increasing the user base is really the goal of session, why on an android device without Google services is it still impossible to get instant, or at least faster notifications?

There are seemingly several ways to solve this issue, foreground service, shorter polling interval etc like many other apps implement, but this one weakness makes it very difficult to recommend to anyone without Google services on their device.

From firsthand experience with many such devices, in different places, I can attest to the fact that the way Signal, conversations (xmpp) and others implement their notification systems works perfectly from a user's perspective.

**Attachments

I have made a couple of issues about attachments recently. As you stated, I get the same red exclamation mark on the circle icon when the file size is to large. I do not get any "file exceeds limit notification". On ios and android the same 6mb file will not send. Why is this when the stated limit is 10mb? When sending this file the screen simply hangs showing the file name and size, with the only active button I can press being "cancel" at the top LHS of the screen.

Also some file formats will not send regardless of size.

I have a certain database (5-7mb) that I need to sync between my devices and have tried signal, wickr and session to go this. Signal and wickr work fine. But if I use session, the destination app cannot recognise or import the database file. What does session do to the file?

**Calling

I understand this feature is in beta, but calls will only connect with certain people, and only maybe 30% of the time. However if connected the call quality is excellent, so kudos for that.

** Explanations and error messages

Ideally there needs to be clear clear error messages explaining to the user why a feature failed to succeed. Why the file wouldn't send, why the call didn't connect, why my message didn't send etc. At the very least a page explaining to the user what all the different icons mean so they can understand where the issue may reside.

I also really appreciate the work to support this project.

I share many of the same issues with development as are discussed here. It seems like the priority of certain features and bug fixes aren't ideal, especially for average users. In fact, this kind of development model reminds me of the reason I now detest ProtonMail's Android app, which has a few similar issues. For instance, FOSS notifications have been a major ask from the PM community for many years, with all their competitors having implemented them, but those requests are constantly ignored for useless reskins of their products and features that should be far lower priority given their user base. I'm seeing some of that here with Session now as well. The notifications are a huge detriment to me, as I need immediate notifications from instant messengers, but the polling frequency for FOSS notifications is 15 minutes. I proposed a number of easy solutions to this in July with #924, but I have yet to see any progress made on what should be a very important feature. Since then, however, we've seen emoji reactions, a UI redesign, and a handful of other features that should not have taken priority over fundamental features like notifications, and especially should not have taken priority over numerous different bugs that need to be fixed.

And that's not even mentioning the fact that Session doesn't have an official build in the F-Droid repository. I am okay with using their third party repo, but I feel like having a version with the Play Services stripped out of it would be quite easy. In fact, just having 2 versions of Session in their third party repo (with names helping differentiate them) for that would be plenty, since I prefer third party repos for a number of reasons from security to convenience.

Through all my issues, I've still continued to use Session, as I very strongly believe in it, but my confidence has been continually declining, and I've found myself recently considering other options for my primary messenger. I still want to use it over Signal for the privacy it adds (no phone number, much better anonymity, decentralized onion routing, etc.), but I've quite honestly had a bad experience with daily driving it, and it's much more difficult to keep my contacts from switching to SMS over Session because I'm the only one who actually cares about using a secure and private messenger. I've had a couple contacts try to force me back to SMS. I may find myself switching back to Matrix, as it's much more mature, and I'm not finding enough value from Session at this point to use it over Matrix.

I love this project and I want to see it succeed, but I don't know that I can continue using it in its current state, especially when the development priorities don't target the issues that the end users are constantly dealing with.

it would help a lot more if we could convert this to a discussion thread and open issues for each of these points in their respective issue trackers.

My understanding is that similar issues are currently opened and have been for some time. For example notifications, just to handpick a couple of examples: 1016, 924, 843. So even when there is acknowledgement that it is possible to implement, and that is a good idea, it seems there is no progress on implementing such a basic and essential feature. This causes some frustration when less essential features are developed. Either way it's nice to have this tool available to use, and thanks to all involved in developing it.

it would help a lot more if we could convert this to a discussion thread and open issues for each of these points in their respective issue trackers.

Agree.

This thread is going viral, I'm sure more people will read it sooner or later, so I'm going to abuse this thread to sell my argument:

Anyone who'd like to help Session improve, please read how to write a bug report, as well as share the knowledge of writing a good bug report with other community members.

I have reported several hundreds of bugs to many different open-source projects in the past, and also fixed a fair amount of bugs by myself. What I have learned is, fixing a bug is much harder than reporting a bug, sometimes it takes months or even years, and the original reporter often lose interest in the bug when a developer finally has time to look into it, so it is important to get a bug report done right in the first place. By learning how to write a high-quality bug report, we are doing our best on our part, which can help save developers' time and make sure it's still clear and easy to reproduce even after several months.

Not representing the session team, just a casual user myself:

Although reporting bugs, UI issues, feature requests especially things that put a barrier in adoption is a hugely important task since a software not used by people is dead software, I would like to warmly request everyone to write down this feedback in a polite tone that invites cooperation and solutions.

I have myself been struggling to migrate myself and close ones to Session, however I believe it's the most promising messenger right now when it comes to delivering privacy and security, thus I want to foster the best environment in which the community and the devs can resolve blocking issues. Respectfully, I sense a tone of frustration in the OP who presents their arguments as if the Session team purposefully are unable to understand the areas in which Session lacks. I think this frustration may come from lack of perceived (or actual lack of) progress, which is fair, but I do not think is fair to express it in such a way on an Open Source project.

The arguments are legitimate understood, I am sure everyone understands why they are important and to which degree, and everyone would like to see them solved yesterday. Since this is not the reality though, we have 2 ways to make that happen (if we actually want this project to succeed):

Contribute our time to fix issues that bother us
Help the people who do the development achieve their goals via bug reporting, user testing, etc.

Please do not underestimate the amount of work that is necessary to make something happen, as a developer myself I have seen things that are visually very simple to do, have a ton-load of complexity under the hood. And also there only so many workhours in a day a team of devs can put in.

Having said all that, I am currently in the process of giving Session another shot at gradual migration and it is way better than were it was last year when I tried again, which, to me, shows clear progress. I hope it was faster progress, but I guess I need to contribute time myself to make that happen.

Eidt:

I feel all these requests have a better chance of having an impact if the people receiving them do not feel their work is being attacked by using negative characterizations.

On Tue, 17 Jan 2023 07:07:41 -0800 gtsop @.***> wrote:

Not representing the session team, just a casual user myself:

Although reporting bugs, UI issues, feature requests especially things that put a barrier in adoption is a hugely important task since a software not used by people is dead software, I would like to warmly request everyone to write down this feedback in a polite tone that invites cooperation and solutions.

I have myself been struggling to migrate myself and close ones to Session, however I believe it's the most promising messenger right now when it comes to delivery privacy and security, thus I want to foster the best environment in which the community and the devs can resolve blocking issues. Respectfully, I sense a tone of frustration in the OP who presents their arguments as if the Session team purposefully are unable to understand the areas in which Session lacks. I think this frustration may come from lack of perceived (or actual lack of) progress, which is fair, but I do not think is fair to express it in such a way on an Open Source project.

i agree, i am doing what i can to push as much as the process behind session to exist on github first.

The arguments are legitimate understood, I am sure everyone understands why they are important and to which degree, and everyone would like to see them solved yesterday. Since this is not the reality though, we have 2 ways to make that happen (if we actually want this project to succeed):

Contribute our time to fix issues that bother us

Help the people who do the development achieve their goals via bug reporting, user testing, etc.

there needs to be an effort given from everyone not just the community or the paid project devs to start splitting these gripes into a set of milestones and bugs. if we can group the bugs into a series of milestones we can really become much more effective at organizing and prioritizing bugfix efforts. more importantly it makes this process accessible to everyone in the wider ecosystem.

manifesto style exposition dumps make this process take longer because we need to pick these kinds of posts into smaller actionable items that can be worked on in a well defined order.

Please do not underestimate the amount of work that is necessary to make something happen, as a developer myself I have seen things that are visually very simple to do, have a ton-load of complexity under the hood. And also there only so many workhours in a day a team of devs can put in.

Having said all that, I am currently in the process of giving Session another shot at gradual migration and it is way better than were it was last year when I tried again, which, to me, shows clear progress. I hope it was faster progress, but I guess I need to contribute time myself to make that happen.

if possible, it would be great if the reporter of this bug can help decompose the set of problems stated into a smaller set of descrete gripes that we can start working on together on github.

-- ~jeff

Hey, I'm the creator of this report/letter... I've been reading all the feedback you all have given here and I'm glad to know I'm not the only one who has good and bad things to say about Session... Thank you for all the feedback!

But there's something very discouraging... Not one single comment from the Session guys here... Not an acknowledgement, not even a "rebuttal" of anything written here, just plain apathy (or maybe lack of maturity to accept criticism).

I would gladly do what @majestrate suggested about decomposing the letter into separate bug reports... but as I said in my letter. English is not even my native language, it took me around 5 hours to write and support with images and videos that first post. This is one of the most commented posts here in the issues section of the Session Github page and yet, not a single comment from the Session team. Sorry, I won't invest more time reporting bugs, giving feedback or helping troubleshoot problems as long as they don't show interest in the subject.

I imagine some people will not like my attitude, but again, there's clear agreement in some of the points exposed here. This is an open source project and I also imagine that less than 0.1% of Session users take the time to report bugs and post here in Github, they should encourage the community to keep reporting bugs and help troubleshooting problems. This apathy is doing the opposite.

I still like Session a lot, but I will invest my limited time helping and giving feedback to other projects more in touch with their users.

On Thu, 26 Jan 2023 12:15:31 -0800 tuqueque @.***> wrote:

Hey, I'm the creator of this report/letter... I've been reading all the feedback you all have given here and I'm glad to know I'm not the only one who has good and bad things to say about Session... Thank you for all the feedback!

But there's something very discouraging... Not one single comment from the Session guys here... Not an acknowledment, not even a "rebuttal" of anything written here, just plain apathy (or maybe lack of maturity to accept criticism).

i am on the core C++ team, we've been working on getting the rest of their dev process onto github as we are now redoing the internals in C++ to mitigate codebase fragmentation and the bugs that arise from such.

I would gladly do what @majestrate suggested about decomposing the letter into separate bug reports... but as I said in my letter. English is not even my native language, it took me around 5 hours to write and support with images and videos that first post. This is one of the most commented posts here in the issues section of the Session Github page and yet, not a single comment from the Session team. Sorry, I won't invest more time reporting bugs, giving feedback or helping troubleshoot problems as long as they don't show interest in the subject.

i can understand this dimension having done a lot of text only dev with i2pd a project mainly with russian native ESL devs, it is understandable that you have a lot of things to articulate. please keep in mind that because of the codebase fragmentation splitting this up into smaller issues is a great way to move this forward, as we can then use issues like these as a kind of master issue that we can resolve as the items are completed.

I imagine some people will not like my attitude, but again, there's clear agreement in some of the points exposed here. This is an open source project and I also imagine that less than 0.1% of Session users take the time to report bugs and post here in Github, they should encourage the community to keep reporting bugs and help troubleshooting problems. This apathy is doing the opposite.

i agree, the way forward we are going with session is to have as much as the dev process be done on github as that is what the core C++ team has been doing all this time. they'll need to adapt this workflow for the C++ core library we'll be having session using. things are improving as as of last week i have seen a 3x activity on github from the session team. very glad to seem them showing the community what they are doing and when, this way we dont need to just say "it's coming soon trust us", they can see the progress in real time so they dont have to take our word for it.

I still like Session a lot, but I will invest my limited time helping and giving feedback to other projects more in touch with their users.

thank you, please continue giving us feedback, just make sure the form it is in is productive. that really helps us a lot when it is.

-- ~jeff

@majestrate Since my comment in this thread makes me sound quite irritated, I want to clarify that I really do appreciate the work that has been put into this project by all its contributors. I really want to see this project succeed, and I think some of my previous annoyance is certainly misplaced.

With that said, I have not experienced all the same problems as OP, so I would have difficulty breaking up their problems into smaller issues. I've opened a few issues in the time I've used the app, with only 1 remaining open (#924). Other than that, I have only personally experienced one other major bug recently, which involved some messages not showing up from another user until I message them. I unfortunately don't have enough information to be confident filing a bug report for that issue, and I have not recently dug through the issues to see if someone else has filed one.

The other grievances in my comment can be broken down as follows:

924 has not seen any progress. A temporary solution would be to allow the user to manually set a lower polling frequency if they want. Ideally, the issue would be fixed by using something similar to Element or Tutanota's FOSS notifications, or maybe even something with UnifiedPush, ntfy, or Gotify.
F-Droid inclusion. There is already an issue open about this (#73). Having an official build posted to the main F-Droid repo would be a nice to have, but honestly I'm content with using Session's F-Droid repo (and I think it is perfectly fine moving forward). I would like an official version with Google services stripped from it in the Session repo though. I could open an issue specifically about that if you think it would be useful.
As others have mentioned, communication generally feels sparse. I don't mind getting vague updates with little information, or just basic acknowledgement. The main issue is when there's no way to tell what's going on with development, or whether a specific issue is being worked on or has priority. I think a roadmap page would help with that quite a lot, just so we know what the priorities are. In fact, I feel as if that would even make it easier for people outside of the core team to contribute to the project. I could also open an issue about that if it would be helpful.

Again, thank you for the work that you and everyone on the Session team has done. Maintaining and improving open source solutions like this is not an easy job.

On Fri, 27 Jan 2023 10:14:56 -0800 Para-lyzed @.***> wrote:

@majestrate Since my comment in this thread makes me sound quite irritated, I want to clarify that I really do appreciate the work that has been put into this project by all its contributors. I really want to see this project succeed, and I think some of my previous annoyance is certainly misplaced.

With that said, I have not experienced all the same problems as OP, so I would have difficulty breaking up their problems into smaller issues. I've opened a few issues in the time I've used the app, with only 1 remaining open (#924). Other than that, I have only personally experienced one other major bug recently, which involved some messages not showing up from another user until I message them. I unfortunately don't have enough information to be confident filing a bug report for that issue, and I have not recently dug through the issues to see if someone else has filed one.

The other grievances in my comment can be broken down as follows:

924 has not seen any progress. A temporary solution would be to

allow the user to manually set a lower polling frequency if they want. Ideally, the issue would be fixed by using something similar to Element or Tutanota's FOSS notifications, or maybe even something with UnifiedPush, ntfy, or Gotify.

i figure this one is near the bottom of their todo list right now. many more sqeaky wheels right now.

F-Droid inclusion. There is already an issue open about this (#73). Having an official build posted to the main F-Droid repo would be a nice to have, but honestly I'm content with using Session's F-Droid repo (and I think it is perfectly fine moving forward). I would like an official version with Google services stripped from it in the Session repo though. I could open an issue specifically about that if you think it would be useful.

i'd like this too, i am not sure why we haven't done this yet.

@hjubb do you know what the blockers on this are? i am guessing it's some kind of internal spegetti that gets in the way of making that a quick win?

As others have mentioned, communication generally feels sparse. I don't mind getting vague updates with little information, or just basic acknowledgement. The main issue is when there's no way to tell what's going on with development, or whether a specific issue is being worked on or has priority. I think a roadmap page would help with that quite a lot, just so we know what the priorities are. In fact, I feel as if that would even make it easier for people outside of the core team to contribute to the project. I could also open an issue about that if it would be helpful.

yeah we can fix this.

Again, thank you for the work that you and everyone on the Session team has done. Maintaining and improving open source solutions like this is not an easy job.

-- ~jeff

@majestrate and @Para-lyzed on the F-Droid inclusion process I think it would look something like this:

create new build variant for google push related services
have some abstract 'base' app variant interface to take care of registration and receiving/processing related stuff
probably just do no-op implementation in the non-google variant source set
do the real implementations in the google variant source set
build system magic to have the required services defined in a separate app manifest that gets merged into a final manifest for the google variant

only problem outside of that is probably just build related, having to apply the various google push notification plugins and moving some stuff around to make it build happily, but that stuff is all mostly non-implementation related. After that it'll basically have two possible implementations of which one is expected, basically the same way we have that as a dimension in the build process of "play" release vs "website" release (which currently just does nothing, we inherited it from forking Signal).

All that stuff would be pre-submission for the official F-Droid repo. Not sure if having the 'non-official' variant already there would complicate that process or not, I think on top of that the F-Droid repo might (unsure of this one) then also sign the builds from their server with their own release keys, which would mean that upgrading from a GitHub release APK or currently installed Session F-Droid repo APK would be incompatible and you'd have to possibly either try install it over the top with workarounds, otherwise just uninstall and reinstall and resync the device.

The new config syncing and related shared library stuff might make the resyncing process a little easier at least if that is necessary. Not impossible stuff to do overall, just annoying things to move around that will probably take more time to do once there's a breather between bigger changes that are synchronized across all the platforms. I'd probably have a better idea as to the actual process once I dig into it but that is as close to what I'd expect it to be atm

i am on the core C++ team, we've been working on getting the rest of their dev process onto github as we are now redoing the internals in C++ to mitigate codebase fragmentation and the bugs that arise from such.

i agree, i am doing what i can to push as much as the process behind session to exist on github first.

I am a user and an open-source contributor, I appreciate what the Session team had done and I'd like to emphasize @majestrate's point, I think it is important to increase the openness and transparency of daily development and get more community contributors involved, this is a key component to the long term success of Session.

I'd like to share my arguments with some figures from the Signal project as an example.

The Signal project was released about 8 years ago, with a relatively small/medium size dev team. Based on my GitHub commit email stats, it has around 60~70 devs from the official team today, and it was much smaller initially. In the past 8 years, the Signal projects continued growing and fixed around 17K GitHub issues, which is a very heavy workload for a small team. However, if we look closer at the number of internal contributions (email address signal.org or moibilecoin.com) VS external contributions, we will realize how the external contributors play a significant role:

	Signal-Android	Signal-iOS	Signal-Desktop	Signal-Server	libsignal
closed issues	~9,700	~2,800	~4,500	N/A	~100
internal contributors	26	29	14	20	15
external contributors	321	165	199	31	20
internal commits	7770	23266	2277	2100	1436
external commits	3784	6858	5151	526	72

Note: The above number might not be accurate because there's evidence showing some internal contributors occasionally use a third-party email address to commit, the internal contribution is likely deflated and the external contribution is likely inflated, but we can still see the big picture.

We can see that for a very low-level library like libsignal, external contributions are rare, for mid-level repo like Signal-Server, external contribution starts to play a significant role, and for high-level applications like Signal-Android/Signal-iOS/Signal-Desktop, the numbers of external contributions are incredible.

This totally makes sense, because low-level library development requires very specialized expertise, while high-level application development is more accessible to most open-source contributors. On the other hand, user behaviors are long-tailed, and bugs are long-tailed. When building a product with a diverse group of users, there are always edge cases that bother a small group of users, the core team either can't reproduce them or does not have resources to take care of them, that's where external contribution becomes a critical factor to the success of the whole project. When those annoying edge cases are fixed, the power of word-of-mouth spreading starts to become unstoppable, every happy user forms a part of the long chain of transmission.

There are already 100M GitHub users according to a recent announcement [1], which is 250 times higher than Session's 400K monthly active users. If we do things right, the pool of potential contributors is incredible, it's a great treasure to be discovered.

Last but not least, the Session project started from forking Signal, which is a pretty phenomenal success, there must be something the Signal team did right that is worth learning from. It would be great if the Session team can make friends with the Signal team, chat about development process improvement, and even get their support. At the very least, there's nothing to lose to make friends with those great people ;)

[1] https://github.blog/2023-01-25-100-million-developers-and-counting/ [2] script

#!/bin/bash

repos=( Signal-Android Signal-iOS Signal-Desktop Signal-Server libsignal )

for repo in ${repos[@]}
do
  echo $repo
  cd $repo;
  short_log="$(git shortlog -s -n -e)"
  internal_short_log=$(echo "$short_log" | grep -e signal.org -e mobilecoin.com)
  external_short_log=$(echo "$short_log" | grep -v -e signal.org -e mobilecoin.com)
  internal_contributors=$(echo "$internal_short_log" | cut -f2 | sort | uniq -c | wc -l)
  internal_commits=$(echo "$internal_short_log" | cut -f1 | paste -sd+ - | bc)
  external_contributors=$(echo "$external_short_log" | cut -f2 | sort | uniq -c | wc -l)
  external_commits=$(echo "$external_short_log" | cut -f1 | paste -sd+ - | bc)
  echo "internal contributors: $internal_contributors, external contributors: $external_contributors"
  echo "internal commits: $internal_commits, external commits: $external_commits"
  cd ..
done

oxen-io / session-android

An "open letter" to the Session team. #1051

924 has not seen any progress. A temporary solution would be to allow the user to manually set a lower polling frequency if they want. Ideally, the issue would be fixed by using something similar to Element or Tutanota's FOSS notifications, or maybe even something with UnifiedPush, ntfy, or Gotify.

924 has not seen any progress. A temporary solution would be to