please use proper versioning

[IzzySoft]

currently, each and every APK at your releases seems to identify as

package: name='com.nostros' versionCode='1' versionName='1.0'

so not only can a user never know what version is installed, but Android cannot tell if an APK you want to install is newer or not either (Android uses versionCode to tell them apart). So for the currently latest release, it should be versionName: "0.2.0.1-alpha" and versionCode: 26 (as it's the 26th release; important with this one is just that you increase it with each version – how much you increase it is up to you, but you can never decrease it anymore without forcing all users to uninstall and reinstall).

Thanks in advance for taking care!

[diegogurpegui]

This is a good point and I agree. However, that's probably left there unchecked on purpose since the app is not in stores right now.

What could be nice is to have the version of the app printed on some screen (eg: the bottom of Config screen).

[KoalaSat]

Believe it or not today I was thinking about it but I had to investigate how to properly do it, thanks for the hints @IzzySoft I'll change it for the next release

[KoalaSat]

https://github.com/KoalaSat/nostros/pull/110

[IzzySoft]

What a coincidence :rofl: Thanks, yes: exactly that was what I meant. So with that PR merged, the next APK built would show up as I described.

As for "not in the stores": Uhuh, that was part of the background to my question. I'm running the largest 3rd-party F-Droid repo with currently more than 1k apps (see here) and was considering to integrate your app there. With proper versioning (and especially versionCode always increased on release), I could finally do that. So if you're OK with this: I could pick some screenshots from your release messages – or you could provide a selection of your choice, plus some app description maybe? Ideally that could be set up using Fastlane structures here in this repo; if I have description, screenshots & Co I could bundle a "starter package" for you.

[KoalaSat]

What a coincidence 🤣 Thanks, yes: exactly that was what I meant. So with that PR merged, the next APK built would show up as I described.

As for "not in the stores": Uhuh, that was part of the background to my question. I'm running the largest 3rd-party F-Droid repo with currently more than 1k apps (see here) and was considering to integrate your app there. With proper versioning (and especially versionCode always increased on release), I could finally do that. So if you're OK with this: I could pick some screenshots from your release messages – or you could provide a selection of your choice, plus some app description maybe? Ideally that could be set up using Fastlane structures here in this repo; if I have description, screenshots & Co I could bundle a "starter package" for you.

If you can do it for me it would be super awesome, you can take the screenshot but just be aware the next feature is drastically changing the UI, but I assume we can change those images at any point on the repo.

@frontendcrypto is helping with the branding so maybe he can help with the description 🙂

[diegogurpegui]

Excellent :)

@KoalaSat I think the version and build bump should be included as part of the GitHub actions flow you have for building. That way it's automatic without you worrying about it. The build (versionCode) bump could be pretty automatic, but the versionName might require manual input in case you increase a minor version 0.x.0 or a patch 0.0.x for example.

[KoalaSat]

Yes I'm pretty sure there has to be some boilerplated GitHub action for that, I'll do the research, but probably if the action makes an extra commit obtaining the info from the triggered release, it can be fully automated, thanks for all the help!

Let us know if you need something else for the repo ⚡⚡

[IzzySoft]

you can take the screenshot

Sorry to disappoint, but I'm not using Nostr so I'm not the best choice for this task. For starters, if you could provide the following, more can be added later:

• short description (max 80 chars)
• full description (a few lines describing the app and giving a clue of Nostr's concept so even those not familiar with it can get an idea). No need for a "fully polished" one, can always be improved later.
• an icon (128x128 to 512x512 px) and some screenshots (again, 3..5 suffice for starters, can be replaced and amended later)

It's totally fine to provide that just in a comment here, I'd then prepare the Fastlane structures and offer them back here for integration if you prefer. Or you give it a try yourself and have me cross-check :wink:

Once the listing is up, it can always be improved and built upon – see my Fastlane Cheat Sheet which I already linked above. Seeing the app size getting close to the limits of my repo already (30M per app; Nostros is already at 26M), per-ABI builds might be a good idea; I'd then pick the armeabi (most wide-spread support on older devices, and most 64bit devices support it as well) or if you prefer the arm64 APK for my repo. Once the app leaves "alpha stage" and is considered ready for a broader audience, I could guide you to get it listed at F-Droid.org (with all 4 ABIs then; disclosure: I'm one of the maintainers there).

[devsigner-xyz]

Hi! What do you think about something like this? I think this would be enough for now, we can always expand it later. @KoalaSat

Short description The first Nostr client on Android. The only and truly uncensored social network.

Full description Nostros is the first Nostr client for Android. Access a social network similar in appearance to Twitter, but decentralized and uncensored.

Nostros offers an extensive list of features that grows every day. Access the global feed or the feed of the people you follow. View all the content that you have liked, been mentioned or disliked.

You can also send tips to users through Lightning Network as well as associate your Nostr identity to your Twitter profile or domain.

Follow other users, or unfollow them. Indicate if you like their content, or if you don't like it. Comment on other people's posts or quote them.

Don't wait any longer and join the most social network thanks to Nostros.

Screenshots

Icons

[KoalaSat]

Awesome! Thank you! Please @IzzySoft let us know if you need anything else

[IzzySoft]

Awesome indeed! I'd just need the info if you would provide per-ABI builds. If not I can of course pick the "fat lady" – but then I could only hold the latest version available in my repo. A single ABI would most likely be below 15 M, so I could keep 2 versions (useful to prevent installation errors when a user e.g. just pulled the index right before a new version was added, and thus would try installing the version that was just purged – with 2 versions kept, it would still be there and the user would just get an update notification the next day).

Of course we could also move to per-ABI builds later – but depending on their setup, the switch might be a problem as usually each ABI has its specific versionCode (example: Flutter per default generates a code of <ABI> x 1000 + versionCode – so once my updater fetched the one with the highest ABI (4000 + versionCode) and it was the wrong one, switching to the other would mean users had to uninstall and re-install as you never can "downgrade" to a lower versionCode). This could of course be worked around by marking the first release with per-ABI builds prerelease (so my updater ignores it) and letting me know, so I can configure it accordingly on my end – and as soon as that's done the "pre-flag" can be removed again. We'd need some "constant patterns" in file names then so I can ensure the correct APK is fetched (usually *armeabi-v7a*.apk for ARMv7, *arm64*.apk for ARM64, and so on).

Just let me know your decision, and we're ready to go (as soon as the APK decided for is available).

[KoalaSat]

@IzzySoft sorry for answering late but right now we are totally focused on migrating the UI, what do you recommend? Don't now and eventually change and use the pre-ABI or it's fine to just for with one big version for now?

[IzzySoft]

As described it's preferable if I can hold more than one APK in my repo, so the per-ABI builds would be the way to go. And no pressure from my end: if your focus is now on migrating the UI, you probably won't release before that reached a "stable point". For the best "first impression", maybe wait for that – and take a look at per-ABI builds when the release comes close? Better have it lean and clean than haste and waste, do you agree? :smile:

An ETA would be nice to have – but if hard to give, I'll just wait and maybe chime in every now and then to see how things stand. I'll certainly do so when seeing a new release – but won't nag you twice a week :wink:

If you prefer going with the "fat lady" now and switch to per-ABI later, that can be done as well – see above for possible implications which are, hopefully, easily solved when planned in advance. I'd follow your preference then.

[KoalaSat]

Hi @IzzySoft again, we are done with the UI and entering the testing stage to be prepared for the Beta version.

I have been investigating a little bit all the info you provided (thank you!) and certainly we can try to go with the per-ABI build. 😄

My only doubt so far is how and from where you'll obtain the generated APK?

[IzzySoft]

Well, I was hoping you'd attach it to your Releases 28, as you currently do with your "fat lady"? AFAIK there are even Github actions to achieve that automatically somehow. Guess ideally you'd attach all of them, but for the purpose to pick one for my repo it would of course suffice to attach the one I shall pick (usually either ARMv7 or ARM64).

[KoalaSat]

Perfect that was my thought, I'll work on the GitHub action to generate both

[KoalaSat]

I make it work locally so I configured the github action, I'm planning to create a new release today/tomorrow so then we can test it out 💪

https://github.com/KoalaSat/nostros/pull/160

[KoalaSat]

[IzzySoft]

That looks great! So whether you decide for armeabi or arm64, at that size I can keep 2 copies in my repo (so on update even those not yet having the latest index won't get an error-on-install as the previous APK is still available). With the "fat lady" aka "universal" I could only keep one.

So once they're up, just let me know which one you'd prefer me to pick. Thanks a lot!

[KoalaSat]

I think you mentioned you preffer to have arm64 on your repo right? feel free to decide which one 😃 I'm still generating the universal for people who directly goes to github to download it.

[KoalaSat]

Also @FrontendCrypto I think with new UI those screenshots are obsolete

[IzzySoft]

I think you mentioned you preffer to have arm64 on your repo right?

I used to take the armeabi APK for wider compatibility (and also for sustainability, supporting those using their hardware as long as it works while not neglecting that arm64 devices are around now for about 5 years, and being the majority of new devices). But I of course respect the wishes of the authors: so if you say you prefer me to pick arm64, I'm fine with that meanwhile (wasn't a year or 2 ago when 32bit devices were still more prominent than today).

I'm still generating the universal for people who directly goes to github to download it.

By all means: yes, please do! If you'd have the universal and all the per-ABI builds here, everyone would have the full choice. That said, while I can check for myself once the APKs are up: what pattern are you using for versionName? Will they all share the same? If not, where will they differ: last digit or first (e.g. Flutter by default and for extra crazyness has them differ in the first digit; so if you start with a 2001 armeabi you'd have no chance switching to arm64 having a 1002 with the next release, which to me is absolute nuts).

with new UI those screenshots are obsolete

Good point! I see you include some with your releases as well, so for starters I could pick some from there. Once set up, I can provide you the metadata in Fastlane format to integrate with your repo here. Then you can update description, screenshots and all to your liking and changes will be pulled along with each new release.

[KoalaSat]

This is the pattern https://github.com/KoalaSat/nostros/blob/main/.github/workflows/android-build.yml#L56

[KoalaSat]

Good point! I see you include some with your releases as well, so for starters I could pick some from there. Once set up, I can provide you the metadata in Fastlane format to integrate with your repo here. Then you can update description, screenshots and all to your liking and changes will be pulled along with each new release.

Perfect let's do it like you say

[IzzySoft]

Ugh, guess I've chosen the wrong phrasing. I meant the "pattern" for versionCode. Would be good if e.g. armeabi had a smaller VC than arm64, so folks switching from an old 32bit device to a newer 64bit while transferring their apps and data would still be able to update from armeabi to arm64 then.

And great, I'll provide the metadata then (should I forget, be welcome to remind me). Looking forward to the next release then!

[KoalaSat]

@IzzySoft here you go https://github.com/KoalaSat/nostros/releases/tag/v0.2.1.2-alpha, I hope everything is correct, please let me know if we need to change something

[IzzySoft]

Thanks @KoalaSat! I've modified the description slightly (there are already 2 Nostr clients in my repo, so "the first" sounds a bit … strange :see_no_evil:). Will show up here with the next sync today around 7 pm UTC. If you like what you see there: be welcome to pick a badge to link there e.g. from your Readme :smiley:

As promised, here's the fastlane.zip with the metadata. Unzipped content should go directly to the document root (i.e. /fastlane). Feel free to replace the screenshots again (my framework compresses & resizes them – other places like F-Droid.org might keep them full-size) and build upon it (e.g. add per-release changelogs and a featureGraphic if you like – my Fastlane Cheat Sheet may be a guidance with that.

Well, all done then I guess – so we can close this issue?

[IzzySoft]

Oh, PS: donations & Co. If you use Github's FUNDING.yml, those details will be picked up automatically with each release. It doesn't support BC, so I've added your BC address manually already here.

[KoalaSat]

Thank you so much @IzzySoft I'll include the fastlane and check all your comments! this is great 🎉 🚀 !

[KoalaSat]

Also I just remeber you mentioned you have some info about how to upload this to F-Droid, do you?

[IzzySoft]

how to upload this to F-Droid, do you?

(Looking for the Meme from Lord of the Rings) "One does not simply upload to F-Droid…" :see_no_evil:

OK, disclosure: Yes, I'm one of the maintainers there. My repo often serves as "stepping stone" on the way to F-Droid (sometimes also used as "testing channel" by apps already there – but then ideally with a dedicated applicationId). And while my main concern about APK size was the size limitation in my repo, it was also one preparation step for F-Droid.org (we recommend this for apps with "larger universal APKs" and do support per-ABI splits – other than my repo, F-Droid would provide all 4 of them).

So: Yes, I'd have "some info". My suggestion would be to start that process when you consider the app sufficiently ready/stable for "the masses". The way would then be to open a RFP (Request For Packaging), where F-Droid's IssueBot would perform some additional checks on your source code (my own bot checked the APK already, so that test it will definitely pass – but IssueBot would e.g. complain when it found some AAR or JAR files, which my scanner doesn't check for). Once the RFP was confirmed, the next step would be bringing the configuration file (com.nostros.yml) to fdroiddata via a MR.

For a more detailed description, see eg. this section in my article on the topic.

[KoalaSat]

Perfect thank you so much for all the tips! I think we can close then this issue 🎉

[IzzySoft]

Gladly! Should there be any question left, just ask. Otherwise I guess we'll meet "over there" once you're ready :smiley:

[KoalaSat]

One last question @IzzySoft , what's the frequency of updates? When should I expect your repo to get the latest version?

[IzzySoft]

Within 24h of your tagging and attaching an APK. Updater runs once a day and publishes within an hour.

For more background: see here and here :wink:

[KoalaSat]

Sorry for reusing this issue over and over @IzzySoft 😄 I think the category is not the right one, can I change it myself?

And another question from @FrontendCrypto , if we don't include pictures for the French version, will it be a fallback to the English version?

[IzzySoft]

@KoalaSat what a coincidence! I just returned home from a meeting with frinds. Right at the time you wrote this comment, I discovered it when setting up a device with the F-Droid client – and returning home immediately fixed it :rofl: So it will be corrected with the next sync. Thanks for bringing it up! Strange it tried to separate the 3 Nostr clients that way with 2 different misspellings :see_no_evil: (that said, I still waiting for a catholic priest coming up with a 4th client called "PaterNostr" :speak_no_evil: :dash:

[KoalaSat]

hahaha perfect thanks for taking care of us! 😄

[devsigner-xyz]

Hi @IzzySoft. We have an issue. Description in full_description.txt differs from what I am seeing in your site. Any clues about why this could be happening?

[IzzySoft]

Certainly. Fastlane was not yet set up on my end as you never signaled it's ready :rofl: Well, once a month my cross-checker would look for it, so I'd have noticed within a few days anyway – but as I did not yet it's not yet there. Enabled that now with the exception of screenshots; don't you think 30 screenshots is a bit overdoing it? If you link to an image gallery, that's certainly OK. But with metadata, I'd say 15 would be quite a lot already. While it's quite impressive what I see there (wow, really!): do you think all of them are needed there (especially kepping in mind people with a "cheap" data plan or on "less than ideal" connections/bandwidth)?

[devsigner-xyz]

Yes, you are right. I created a PR reducing the number of images. I don't know about signal when is ready.

[IzzySoft]

I created a PR reducing the number of images.

Thanks!

I don't know about signal when is ready.

I took care of that by subscribing to your PR, so I will receive a notification once it's merged :smile:

[devsigner-xyz]

I created a PR reducing the number of images.

Thanks!

I don't know about signal when is ready.

I took care of that by subscribing to your PR, so I will receive a notification once it's merged :smile:

Oh! Sorry I completely misunderstood you 😅

[IzzySoft]

No prob, we managed :rofl:

[KoalaSat]

Hi again @IzzySoft an user just noticed that we had again some warnings of anti features https://apt.izzysoft.de/fdroid/index/apk/com.nostros the script https://github.com/iBotPeaches/Apktool/raw/master/scripts/linux/apktool didn't raised any problem and this time I have no clue of which library is the responsible

[IzzySoft]

@KoalaSat you can always check with the libraries section in my repo's web interface. Or use my library scanner yourself, it's all FOSS :smiley: For a guide, please see: Identify modules in apps.

The culprit is MLKit, dragging in the other dependencies. Why do almost all Nostr clients include that one now? QR Codes I guess, but there are alternatives – apps like Conversations (XMPP) show that's possible.

[KoalaSat]

I think your guess is correct I recently included a QRCode reader library, thanks for you help!

[IzzySoft]

Thank you for taking these things seriously! Keeping my fingers crossed then you find an easy replacement that works to your full satisfaction :crossed_fingers: