Large Telegram messages should go on pastebin about teleirc HOT 22 OPEN

I would like to work on it.

from teleirc.

For future reference when this gets worked on, we can use Fedora's Pastebin. They have a well-documented API to work with:

• https://paste.fedoraproject.org/api

from teleirc.

With that being said, do we want to have an ENV option to set a length of time for the paste to be active for? Or do we just want this to never expire.

from teleirc.

WWeeelllll, it looks like paste.fp.o is being retired in favor of another solution. It may not be a good idea at this point to create this feature surrounding that platform.

from teleirc.

I've got the idea of what to implement, Thanks @jwflory and @kennedy

For utilizing CentOS Paste : We would require an API_KEY to create the paste and i am unable to find a way to generate the API Key.

Any other pastebin service with a decent API would work wonders too. What do you guys think ?

from teleirc.

@nasirhm hello!

I reworded this issue to specify large TG messages. What we did in the previous iterations of TeleIRC is made all newlines within a TG message still fall under the same IRC message, so that way a 5-line TG message still gets sent to IRC as a single message. Additionally, we had a maximum message limit, and split out large messages that went over this limit into separate messages.

As we don't currently have this feature implemented in Golang (v2.0+), we can turn this issue into two parts:

1. Newlines (\n) get captured to send multiline messages as a single IRC message, instead of having them all individual
2. Very large messages (maybe over 500 chars?) go onto a pastebin instead, regardless of newlines

These two points would be separate blocks of work (and thus separate issues/PRs), but would ultimately work together. Thoughts?

from teleirc.

Hey @Tjzabel Thanks for the update, I've been a little busier in the past days and now am back. The very large messages sounds good to me.

@jwflory what do you think about over 500 chars ?

from teleirc.

@Tjzabel It is also worth noting that paste.fp.o is ephemeral. Pastes will eventually expire and be deleted. We should consider if this is something we are okay with or if persistent pastes are important. I lean towards wanting persistence.

from teleirc.

@jwflory it's worth noting that while paste.fp.o is generally ephemeral, there is an option to set no expiry date when uploading through their API.

from teleirc.

@Tjzabel Oh, actually yes! I like giving this option to the user, maybe with a default value of a 90-day expiration.

from teleirc.

This ticket was pushed to the backlog for now. This could be a good candidate for a v1.5 sprint. In the meanwhile, sprint development time will not be allocated to this ticket for now.

If someone in the community wanted to work on this or make a contribution, this would be an excellent place to start! 🎉

from teleirc.

Hastebin is another reliable favorite. You can send txt documents directly to their backend for easy uploads.

from teleirc.

@Tjzabel:
WWeeelllll, it looks like paste.fp.o is being retired in favor of another solution. It may not be a good idea at this point to create this feature surrounding that platform.

I think because this was associated to the fpaste utility, the Fedora pastebin site is now maintained by the Red Hat Community Platform Engineering (CPE) team under the centos.org domain:

https://paste.centos.org/api

So, we could use the CentOS pastebin API.

@nasirhm:
I would like to work on it.

Awesome, thanks for your interest @nasirhm! 🙌 How are you thinking to approach the implementation? Any thoughts?

from teleirc.

@jwflory
Awesome, thanks for your interest @nasirhm! raised_hands How are you thinking to approach the >implementation? Any thoughts?

I'm setting up the development environment first, after that would try to go through the code and on the approach to implement this is what i think:

• A user from the TG side types a message.
• If the message had \n character in it, we can send complete text to the paste.centos.org API and send the link instead.

It's a pretty basic abstraction of how I would approach the problem. What do you think ?

from teleirc.

@nasirhm This is good. Initially I was thinking it would be better to count the number of characters up to the max message length permitted for IRC. I think \n should actually create multi-line messages, but if a particular line is longer than the permitted IRC message max, then that line should go to a pastebin service.

Does this explanation make sense? Curious what other @RITlug/teleirc-developers-commit-access folks think.

from teleirc.

I think the irc message size limit is around 510 characters + 2 command characters. anything bigger definite should be a pastebin.

I often have multiline replies on telegram, and doesn't seem appropriate to auto-assume a pastebin for new lines.

like this reply is 321 characters, i think is fine without a pastebin

from teleirc.

@nasirhm Looks like there might be a single key used across the entire CentOS Pastebin Service (see here). I don't think we want all of our users to ask Fedora Infrastructure for the single key…

So, any other service is fine. I think it is a requirement that it be an open source pastebin tool with self-hosting options, for other downstream TeleIRC users. This way, they could also configure a different base URL if a downstream TeleIRC User wanted to use their own internally-hosted Pastebin Service.

from teleirc.

+1, I am on board. 😄

from teleirc.

@jwflory /me is working on it now.

from teleirc.

This seems to be too complicated for a "good first issue" as listed in https://fedoraproject.org/easyfix/ please consider removing it.

from teleirc.

I don't agree, this isn't that insanely complex. It requires knowledge of how both Telegram and IRC work and then it's a matter of checking the message length and making a request to a pastebin service via an API.

from teleirc.

IMHO this is PERFECT for Hacktoberfest. Hacktoberfest is about getting good quality PRs and this is good for that.

from teleirc.