Dave . . .

On Sun, 31 Oct 2021 06:22:42 -0000, "Dave Sergeant" <dave@davesergeant.com>
wrote:

If there is an
issue with spam and the like with some providers they should be
addressed as such and there should never be a requirement to tell users
how to access the service.

I agree here. Let's fix the problem and not work around it or cover it up by
ignoring it and using another way to post and read messages.

Donald


----------------------------------------------------
Some ham radio groups you may be interested in:
https://groups.io/g/ICOM https://groups.io/g/Ham-Antennas
https://groups.io/g/HamRadioHelp https://groups.io/g/Baofeng
https://groups.io/g/CHIRP https://rf-amplifiers.groups.io/g/main

I appreciate the app for those who want to use groups.io on their
smartphones. But for many of us our computers are what we use to keep
in touch with the rest of the world and primarily by email. I, and
don't think I am alone, don't even have a smartphone. If there is an
issue with spam and the like with some providers they should be
addressed as such and there should never be a requirement to tell users
how to access the service.

Dave

On 30 Oct 2021 at 20:29, Joe Keliher wrote:

I want to encourage our group members, especially Comcast email users,
to use the App, not email, to avoid similar problems in future.

http://davesergeant.com

Our small group (66 members) recently had problem when Comcast flagged as Spam the first message sent from a new group member.  Some members never received that message as email, and assumed it was a Groups.io problem, asking me, the moderator, to “fix” the problem.  (See bottom of this message for the details of the Comcast Spam incident.)

 

I want to encourage our group members, especially Comcast email users, to use the App, not email, to avoid similar problems in future.  Four app features need to be added or tweaked for it to be an effective email replacement.  All 4 should be independent of the user’s “Email Delivery” setting.  Users who use the app as their primary Groups.io tool may not want any group emails filling their Inbox.  My observations concerning these requested features are using Build 40 (most recent) of the mobile app on iOS15 and iPadOS15 on 10/29 and 10/30/21.  Some of these new features may take a lot of programming work, so I understand they won’t be quick fixes.

#1: App Notification to their devices that a new message or reply has been posted to the group – even when they have Email delivery set to “No Email”  i.e. decouple Notifications and Email Delivery.  This Suggestion is being discussed in Beta group topic “Web/App notifications mean emails are not necessary”  https://beta.groups.io/g/main/topic/85983447#30644.  At present Notifications are coupled to “Email Delivery” so that notifications are only sent for  “Individual Messages” or “Full Digest” or “Plain Digest” but not for “Daily Summary”, “Special Notices” or “No Email”. 

 

#2: A badge on their List of Groups indicating the number of new & unread messages. [I don’t know if the badge # is the number of Topics with a new post or the total number of new messages including replies. I have not had time to dig that deep.]

 

The current badge# means “New Message” in the list, but it does not mean “Unread”.  I believe those badges disappear after you have displayed the list on any one of your devices, not after you have read the messages.

 

This works simply on iPhone app that has one screen for “Your Groups”.  However, the iPad (tablet) app has 2 “Your Groups” lists.  Only the one in the top menu-bar drop-down list contains the number badges so the user needs to remember which list to look at. 

 

 

#3: An “Unread” flag in their list of messages indicating each unread message or reply in that group. Ideally, the “Unread” flag should persist on each message until that message is actually opened (read), i.e. the same way most email clients work.   

 

Currently the list of topics has a blue dot in front of new topics, but the dot persists only until the user views the list of topics for the first time on any of their devices.  So at present the blue dot means “new in this list”.  It does not mean “Unread” or “Unopened”.  Obviously that requires the app to track more detail of user activity, so it may be a low priority right now with so many features being added to the app.  But email clients have been tracking “Unread” status for a long time.

 

this was discussed in Beta group topic “Remember last message read” in sept 2019

https://beta.groups.io/g/main/topic/33132716#22159

I have not found a recent discussion of this topic

 

 

#4: Ability for the user to Mark as “Unread” messages they have already opened.  This is a common email tool that many users rely on to flag emails they  need to re-read after a first cursory glance.

 

This topic was discussed in Beta group in Aug 2018 under topic ["mark as unread" function]

https://beta.groups.io/g/main/topic/24166360#17863

I have not found a recent discussion of this pertaining to the app.

 

Marking individual Topics as “Unread” could be added to the ▼ drop-down context menu in the list of topics.  Marking individual messages (original or reply) could be added to the [Reply – Like – More]  menu bar that appears below each reply after a topic is selected all replies are displayed.

 

 

#5:  Update the Member Manual to include all these details, including the interaction (if any) between Email Delivery setting and Notifications.

 

 

Context: Comcast Flagging some messages as Spam

On Aug 29, 2021 Comcast email server automatically flagged as Spam the first message sent out by a new member of our group (who has a gmail address).  I doubt Comcast servers reported this Spam flag back to Groups.io because none of those members were temporarily suspended from the group.  I do not know if this Spam flagging was due to a recent algorithm change at Comcast; Our group had only been operational on Groups.io for 9 months when this occurred.  Only Comcast users in our group reported this message as missing. 

 

The impact on our 11 members with Comcast email varied, probably based on their type of email connection and their Spam setting.

A: Those with Spam filtering turned off got the message in their inbox. 

B: Other members found the message quickly in the Junk or Spam folder of their primary email application.  [I suspect those use Comcast webmail or an IMAP account so their Inbox and Spam folders actually reside on the Comcast server, not on their computer.] 

C: A few members could not find the message anywhere in their primary email application – not in Inbox or “Junk” or “Spam” folders.  Those (including my wife) likely use a POP account that downloads the contents of their Comcast Inbox (only) to an email client on their computer.  Since the missing message had been diverted to the Spam folder on the Comcast server, it never got downloaded to their computer.  The only way to find the missing message was for them to log into their Comcast account via webmail and look it ITS Spam folder.  [Most POP account users (including my wife) don’t even know this separate Spam folder exists on the Comcast server.]  Comcast automatically deletes mail from that folder after 7 days, so the recipient would never see the email at all if they waited 8 days to look for it on the Comcast server.

 

Request: Perhaps Groups.io software engineer could discuss this problem with Comcast to avoid similar automatic flagging as Spam when a message is sent out by a new member of any Groups.io group; i.e. that sender’s address is new to the recipients’ Inbox or “Previous Recipient’s” list.

Changes to the site this week:

October 28, 2021:

• NEW: On the mobile view of the /groups page, added a sort by activity icon.

October 27, 2021:

• NEW: On the mobile view of the /groups page, added red unread badges over the group icons.
• BUGFIX: When paying an overdue invoice, the credit card brand and last 4 digits was not recorded in the invoice record, causing an erroneous Sponsorship reserves entry to be displayed as the Payment Method in the group billing page.

October 25, 2021:

• NEW: The Update Folder dialog box now has a Notify Members checkbox.
• BUGFIX: When renaming a file, even if the Notify Members checkbox was checked, a group notification was not generated. Discussion
• NEW: The Files section Move dialog box now has a Notify Members checkbox.
• BUGFIX: Web-originated private replies to group messages where the sender is subject to DMARC re-writing would have a From line with an incomplete 'via ' part. The Reply-To was correct however.
• BUGFIX: There was an extra leading / in file modification notification messages. Discussion

The next #changelog will be sent on Friday, November 5th.

Take care everyone.

Mark

Bruce,

>>> I've no strong opposition to your observations, but am not yet convinced these are bugs.

I must admit the particular scenario that caused it is on the not-often side, I got caught in the technicality of it I guess. :)

>>> Should groups.io moderators be allowed to Reject (as opposed to Delete) a message from a non-member? Seems that most such messages would be spam, and rejecting it (which sends back a response to the sender) would just encourage more spam.

I agree, from a non-member of course not.

>>> Having the same button appear in the pending list view makes sense because you might have other messages in that list that are from actual members.

Yes, I wasn't referring to removing the reject button in list view but just restricting it, because if you think about it, right now we are letting the mod do in pending list view what we're trying to prevent them from doing in pending message view.  Right now we don't allow the mod to reject any non-member message in message view, but we allow the mod to go back to the list view and check that same message and click on Reject and get to it that way.  Technically the list view's Reject option should also get disabled if any non-member messages are checked and only enable if none of the checked messages is a non-member message.

But on the practicality side, this wouldn't allow anymore the capability of mods (like in the causal GMF topic) to do what they normally do and contact the member (in that particular situation of having a member with a pending message leave the group before the message was worked-on. (or even in the future if that or any ex-member sends in a message).  So from that perspective then, we can let sleeping dogs lie and keep it as a mod convenience/workaround for contacting known ex-members.  (but can also be used to contact non-members if the mod knows the sender)

I guess either way can work, here's a possible tweak that works both ways.  Attached are the two screens, never- non-member and ex- non-member.  You can see they both hide the reject button in message view but have a visual difference, the NM badge.  In the NM side it's obvious why there's no reject button but on the ex-member side there's no indication whatsoever as to why reject is missing.  We don't have an "Ex/Past-Member" badge.  So maybe the reject display code in message view, instead of just checking if the person is a non-member, could also check if it's an ex-member and in that case show the reject button instead of hiding it since we know those ex-members are not spammers.  This way mods won't be able to reject non-member messages but will be able to reject past-member messages.

>>> There is a "Save and Approve" button in the Edit message screen. Why not use that?

You're correct, I didn't mean it overall pending functionality-wise, again strictly technical, and based on what "save" usually does.  "Save and Approve" saves, approves, and having no choice takes you to the next message in the list, or the list view itself if we were at the last message.  I thought plain "Save" (not "Save and Next") should take you back to the existing message you just saved. But I don't mind really, it just caught me by surprise.

Cheers,
Christos

Christos -- I've no strong opposition to your observations, but am not yet convinced these are bugs. 

1. When editing a pending message and click on Save, the message is saved but then you are returned to the next message in the queue, not the one you were editing, resulting in having to go back in the pending message list view in order to approve the message you just edited.  If you edited and saved the last pending message on the list you're instead returned to the list.  It's almost like the Save and the Skip buttons are executed instead of just Save.

There is a "Save and Approve" button in the Edit message screen. Why not use that?

2. There is an inconsistency in the availability of the "Reject" button and NM/Non-Member pending messages.  In the pending list view, you can select that message and reject it.  But if you click on the same message and go into pending message view, the "Reject" button is not shown.

Should groups.io moderators be allowed to Reject (as opposed to Delete) a message from a non-member? Seems that most such messages would be spam, and rejecting it (which sends back a response to the sender) would just encourage more spam.

Having the same button appear in the pending list view makes sense because you might have other messages in that list that are from actual members.

I hope I'm making sense here!

Regards,
Bruce

Hi Mark,

There's a couple of problems in the pending message queue process.

1. When editing a pending message and click on Save, the message is saved but then you are returned to the next message in the queue, not the one you were editing, resulting in having to go back in the pending message list view in order to approve the message you just edited.  If you edited and saved the last pending message on the list you're instead returned to the list.  It's almost like the Save and the Skip buttons are executed instead of just Save.

2. There is an inconsistency in the availability of the "Reject" button and NM/Non-Member pending messages.  In the pending list view, you can select that message and reject it.  But if you click on the same message and go into pending message view, the "Reject" button is not shown.

Cheers,
Christos

Would it be possible to allow payments for sponsorships and donations without requiring a member to login? Many of our members are email only and do not know or care about whether they have an "account" and password. 

This would reduce some "friction" a donor/sponsor who only use email might experience in making a payment. I understand the payment would not be associated with an authenticated member as appears in the activity log now. Perhaps the process could (optionally) ask for an email or other information to identify the donor/sponsor if not logged in.

Thank you.

On Tue, Oct 26, 2021 at 11:22 AM, D R Stinson wrote:

David -

[snip]. If you're using a different palette, that palette may need to be included with the file. You might experiment with that possibility.

 

 Oh, yeah. I forgot to mention this. In a .png file, the palette is actually embedded in the file itself. It (the palette) is optional, and can accommodate up to 48-bit color encoding. I don't think there are any graphics cards around that support color depths beyond 30 bits. The extra  bits (software only) are used to minimize rounding errors in interpolation / smoothing algorithms that use floating point arithmetic, I think.
--
David Bryant
Canyon Lake, Texas
https://t-vog.groups.io/g/main    https://davidcbryant.net

On Tue, Oct 26, 2021 at 02:02 PM, Christos Psarras wrote:

David,

I'm not sure if you embedded those PNGs in your message through email or online, but it seems emailed 256-color/8-bit embeds retain their colorspace encoding but online embeds get upscaled to 16 million colors / 24-bit, so for online embedding that doesn't seem right and it would increase file size. [big snip ...]

I composed the message at the web site. I'll experiment with emailing images instead, sometime. I don't often do that because of minor incompatibilities between the HTML generated by KMail, my email client, and the HTML processor at the web site. These incompatibilities often cause rendering problems in the broadcast message. So I usually use the web site to compose new messages.

Thanks for the information about jpeg compression. That's interesting.
 
--
David Bryant
Canyon Lake, Texas
https://t-vog.groups.io/g/main    https://davidcbryant.net

On Tue, Oct 26, 2021 at 11:22 AM, D R Stinson wrote:

David -

Two possibilities come to mind. Do you have the image size limited to 1024 x 1024 or smaller? Can you convert them to JPG files instead of PNGs?

 

I suspect the system was designed around common JPGs, and PNGs might be confusing it. If you're using a different palette, that palette may need to be included with the file. You might experiment with that possibility.

 

I've used one of several draw programs for image compression, but I've found that in many cases Irfanview does a credible job quickly.

Most of the images I use are screenshots. So the only "limit" on image size is my monitor, which is 1920 x 1080 (often "dumbed down" to 1600 x 900 -- I'm old, and my eyesight is failing). I usually take a shot of just a portion of the screen, so my images are rarely any larger than 1024 x 1024.

I played around with GIMP, the GNU Image Manipulation Program (https://www.gimp.org/). In general, converting a .png file to .jpg format increases the file size by some 100% to 150%. That's for screenshots. If I were processing photographs, .jpg would most likely be the better choice, in terms of file size. But screen shots of web sites usually contain a lot of straight lines and sharp corners, which are more compactly encoded by the .png algorithm. Oh, yeah. JPG files have been around since 1992. But PNG came along in 1997, and software support for the newer format is fairly ubiquitous. I'm sure Mark uses programs that support a great number of file forrmats. For instance, the aforementioned GIMP (free software) supports 40 different file formats, from als to xwd.
 
--
David Bryant
Canyon Lake, Texas
https://t-vog.groups.io/g/main    https://davidcbryant.net

On 2021-10-26 15:02, Christos Psarras via groups.io wrote:

I'm not sure if you embedded those PNGs in your message through email or online, but it seems emailed 256-color/8-bit embeds retain their colorspace encoding but online embeds get upscaled to 16 million colors / 24-bit, so for online embedding that doesn't seem right and it would increase file size.

To clarify, this happens during online posting on embedded PNG images which are bigger than 640 pixels and need to be scaled down.  If 640 or less they stay the same colorspace.

Cheers,
Christos

David,

I'm not sure if you embedded those PNGs in your message through email or online, but it seems emailed 256-color/8-bit embeds retain their colorspace encoding but online embeds get upscaled to 16 million colors / 24-bit, so for online embedding that doesn't seem right and it would increase file size.

But there's also the matter of image compression value when saved to the cloud.  From trial & error, for jpegs at least, it seems 20%-25% is the compression factor used when images get saved on the cloud.  If you send in a jpeg or possibly other compressible formats as well, saved with anything above that, the returned image in the message comes back bigger in file size. (for the same dimensions)

Not to hijack the thread but the interesting thing though, to me at least, is not embedded images but attached images in messages.  Even those get compressed at that cloud compression value so one gets back attached jpegs which are not the same ones as sent in.  (this is for jpegs at least, uncompressed images such as BMPs do come back the same)  For example, an attached 1959x1306 jpeg saved with 5% compression, 1,332kb, comes back with the same dimensions but only 629kb so it was compressed higher when stored on the cloud. I can see embedded images get changed/manipulated but I was under the impression attachments do not get messed with. This may be disconcerting to folks who count on image fidelity or archival quality in their attachments in their messages.  But I guess one should use Photos or Files for archival quality purposes as no image processing takes place in there.

Cheers,
Christos

---

Yesterday I posted a message to my group that included two .png image files. The files I uploaded from my hard disk had these characteristics.

Image #1: 1043 x 543 pixels, 51,102 bytes
Image #2: 1011 x 614 pixels, 34,600 bytes

In the archived version of the message on the groups.io web site I find these file statisics.

Image #1: 640 x 327 pixels, 124,301 bytes
Image #2: 640 x 381 pixels, 89,969 bytes
(these images are stored in the Amazon "cloud")

In terms of display area, groups.io shrank the first image by 63.05% and the second by 60.72%. (The two percentages are different because of different aspect ratios.) But the file sizes increased: by 143.24% and 160.03%. respectively.

So here's my question. Why does a lower resolution image take up so much more disk space?

I have a hunch that it relates to color encoding and the program Mark is using to rescale every image that's more than 640 pixels wide. I had gone to some trouble to compress the images using a 256-color palette and 8-bit color codes. I used an open source program called "pngquant" (https://pngquant.org/). I suspect that the program which rescaled the images desstroyed the color palette and reverted the images to 24-bit color codes. Assuming that's what happened, is there an easy way around it? For instance, what if I resized the images to be 640 pixels wide before uploading them to the groups.io servers? Would the image processing algorithm leave them alone? Or would they still get a whole lot bigger? Are the file sizes increased by groups.io software? Or is that a "feature" of the Amazon "cloud"?

I'll do some experimenting to find out (by sending a private message to myself, and not to the whole group). It's not a big deal, so far as I'm concerned. I'm far, far under the 20 GB "free images" threshold for a premium group. Still, for somebody with a lot of stored images. it might make a difference in the amount the group is charged for image storage. People might even appreciate it if image compression via pngquant were offered as an opion on the groups.io web site. Email messages with smaller (in bytes) images would download faster, etc. So I thought I should mention it here.
--
David Bryant
Canyon Lake, Texas
https://t-vog.groups.io/g/main    https://davidcbryant.net

Yesterday I posted a message to my group that included two .png image files. The files I uploaded from my hard disk had these characteristics.

Image #1: 1043 x 543 pixels, 51,102 bytes
Image #2: 1011 x 614 pixels, 34,600 bytes

In the archived version of the message on the groups.io web site I find these file statisics.

Image #1: 640 x 327 pixels, 124,301 bytes
Image #2: 640 x 381 pixels, 89,969 bytes
(these images are stored in the Amazon "cloud")

In terms of display area, groups.io shrank the first image by 63.05% and the second by 60.72%. (The two percentages are different because of different aspect ratios.) But the file sizes increased: by 143.24% and 160.03%. respectively.

So here's my question. Why does a lower resolution image take up so much more disk space?

I have a hunch that it relates to color encoding and the program Mark is using to rescale every image that's more than 640 pixels wide. I had gone to some trouble to compress the images using a 256-color palette and 8-bit color codes. I used an open source program called "pngquant" (https://pngquant.org/). I suspect that the program which rescaled the images desstroyed the color palette and reverted the images to 24-bit color codes. Assuming that's what happened, is there an easy way around it? For instance, what if I resized the images to be 640 pixels wide before uploading them to the groups.io servers? Would the image processing algorithm leave them alone? Or would they still get a whole lot bigger? Are the file sizes increased by groups.io software? Or is that a "feature" of the Amazon "cloud"?

I'll do some experimenting to find out (by sending a private message to myself, and not to the whole group). It's not a big deal, so far as I'm concerned. I'm far, far under the 20 GB "free images" threshold for a premium group. Still, for somebody with a lot of stored images. it might make a difference in the amount the group is charged for image storage. People might even appreciate it if image compression via pngquant were offered as an opion on the groups.io web site. Email messages with smaller (in bytes) images would download faster, etc. So I thought I should mention it here.
--
David Bryant
Canyon Lake, Texas
https://t-vog.groups.io/g/main    https://davidcbryant.net

On Tue, Oct 26, 2021 at 01:18 AM, Christos Psarras wrote:

Out of curiosity, what is the time threshold that determines whether notifications "lump together" in a single message or go out by themselves?

I believe the window is roughly 5 minutes (ref: https://beta.groups.io/g/main/message/25375).

A side effect of this feature is that affected notifications never go out right away...they are always 5 minutes "late", waiting to see if you make another change within the window.

Regards,
Bruce

On Tue, Oct 26, 2021 at 12:18 AM, Christos Psarras wrote:

Out of curiosity, what is the time threshold that determines whether notifications "lump together" in a single message or go out by themselves?

I believe the latest information is 4-8 minutes, plus your email checking delay.  https://beta.groups.io/g/main/message/25552

Duane

Hi Mark,

>>> This has been fixed now.

Out of curiosity, what is the time threshold that determines whether notifications "lump together" in a single message or go out by themselves?  I've noticed that if I do a few things within some minutes those come in a single message, it pays to be fast I guess.

Interestingly, all those single "File Notifications" messages thread together in a single topic.

Cheers,
Christos

On Sat, Oct 23, 2021 at 12:45 PM Glenn Glazer <glenn.glazer@...> wrote:

Steps to repro:

1) Upload a file, do not click notify members.
2) Used the update icon to rename the file
3) When doing 2), click Notify Members
4) Afterwards, no one gets a notification, including owners and moderators.

This has been fixed now.

Also, I have added `Notify Members` checkboxes to both the Rename Folder dialog as well as the Move File dialog.

Thanks,

Mark 

Many thanks, Mark.

Best,

Glenn