This is just a random topic for keeping track of plugin ideas. Feel free to comment with your plugin ideas so others can discuss them!
A “smart-link” plugin might be nice. For example, here I can enter RR 4657 and it’ll turn into a link. For example: RR 4657.
This would need a fair amount of plugin configuration which is a bit lacking at the moment, but could also be managed via commands.
A “quotes” plugin where the user can add random quotes and then send a random one. It would be nice to be able to have groups as well.
I recently discovered that the 8-ball plugin in the plugin pack had something similar but the quotes/phrases were all statically compiled in. Making them user modifiable would be much more fun.
I’m thinking the main interface would be via sub commands, which means this could be a libpurple plugin.
Something like /quote random would pick any random quote and send it. Likewise, /quote random <group-name> would be a random quote from the named group.
Groups would be created with /quote add-group <name> and removed with /quote remove-group <name> although that should have a flag if it’s going to delete quotes.
Likewise, quotes would be added with /quote add <group-name> <text> and removed with /quote remove <group-name> <text>.
And of course we’d need to be able to list groups with /quote list-groups and quotes /quote list-quotes <group-name>.
A stats sub command could be nice too to display how many groups and total quotes are stored.
Multiline quotes might get weird here, but we’ll have to see how that’d work.
Storage would probably just be a GKeyFile stored in the user’s config directory something simple like:
[star wars]
0 = well hello there
1 = sith lords are our speciality
[star trek]
0 = resistance is futile
1 = Sir, I protest, I am not a merry man!
[doctor who]
0 = Bow ties are cool
1 = ASSIMILATE!
i hope file transfers as they exist in pidgin 2(XEP-0096) won’t be in plugins but in core functionality?
i really prefer that to the http_upload way. i understand that i am a minority here, and i use that http_upload myself, and people use it, and it will be like that.
but i use XEP-0096 file transfers whenever possible, it is so convenient to just send a file, it was sent, it was received, that’s all.
http_upload has the following problems:
- uploaded files get stored for unknown amount of time on someone’s server. unencrypted. i think people exchange with http_upload even important documents. getting access to such a server that stores years of uploaded files may expose lots of private data.
http_upload is misleading because people think their xmpp message is e2e encrypted while the http_uploaded file is not.
- when other person accesses the uploaded file, the server gets to know about the activity patterns of that person.
usually xmpp server protects our activities. it got the message for us, and the sender server doesn’t know when that message was read, or if it was read, if we don’t enable read receipts. http_upload exposes also an ip of the person who accessed uploaded file.
so yes i prefer old good XEP-0096 file transfers.
This thread is meant for discussing plugin ideas not core features. To quote my response from devel@conference.pidgin.im
(05:17:19 PM) grim: modern omemo will not be a plugin, it should have always been built in and we’re not making that mistake again
(05:17:40 PM) grim: audio-calls should also not be a plugin and will be built in directly, we’re getting there slowly but surely
(05:18:34 PM) grim: to be clear, the days of adding core protocol functionality via plugins is something we’re trying to very much avoid in purple3/pidgin3
(05:19:33 PM) grim: and yes i’m considering omemo and media as core protocol functionality
Likewise, file transfer methods that are part of a protocol should be built in and not a plugin as well.
To reiterate in a more generic fashion, if something is part of a protocol, including standardized extensions like XEPs, they should be part of the protocol themselves and not implemented via a separate plugin. It seems like I need to write a post on how we came to this decision so I can point people to it in the future.
1 Like
I am sorry, i did not understand that.
What i use is psychic mode, history, xmpp console. i assume http file upload and service discovery, as well as receipts will be available without plugins.
Today I had an idea for a plugin. These ollama etc model runners, they all do speak one http api, right? So I assume people could use pidgin to chat with llms, instead of heavy js-bloated web uis.
1 Like
Today I had an idea for a plugin. These ollama etc model runners, they all do speak one http api, right? So I assume people could use pidgin to chat with llms, instead of heavy js-bloated web uis.
There’s a ChatGPT already, but I’m not aware of any others.
Would be neat to have a plugin for turn-based correspondence games (e.g. checkers, chess, Connect Four) where you send people a move as a chat and they make their move and send it back. On iOS, GamePigeon (fitting name) is an iMessage plugin that does this and was popular in my school when it first came out. Not sure how the UI would look (maybe the plugin could provide some kind of popup window?) but would be fun. Would be nice if it were protocol-agnostic but would be confusing/possibly marked as spam if the raw game data got sent to someone without the plugin. Maybe game state could be sent in an attachment file to separate it from the message text.
2 Likes
It would be nifty if we could detect links to stuff like rick rolls and other things and warn the user. A plugin could scan a message for links and look for something like https://www.youtube.com/watch?v=dQw4w9WgXcQ and then highlight the message and give it a title like “WARNING: rick roll”.
true! how we forgot about turn based exchange? psi has chess (though i did not manage to make it work).
another idea i have remembered: i know some people are insisting on using otr, instead of omemo.
and, would be good to be able to subscribe to xmpp feeds/microblogs.
such are provided by known projects like movim, libervia. there is a project called rivista. It describes what technologies are used for publishing:
`RFC 4287: The Atom Syndication Format < RFC 4287: The Atom Syndication Format | RFC Editor >`_
`RFC 5005: Feed Paging and Archiving < RFC 5005: Feed Paging and Archiving | RFC Editor >`_
XEP specifications
`XEP-0060: Publish-Subscribe < Publish-Subscribe >`_
`XEP-0277: Publishing Over XMPP < Microblogging over XMPP >`_
`XEP-0472: Pubsub Social Feed https://xmpp.org/extensions/xep-0472.xml`_
ok, another thing i was wanting to implement, but as i understand, it is not possible with pidgin2, is a “talk” like communication plugin.
i mean unix talk, and then something like that was also in icq at some point.
the window was divided into separate areas for each participant.
- characters appeared remotely keystroke by keystroke, without pressing Enter.
- the other person could see pauses, corrections, and backspaces as they happened.
- it could support more than two participants, with each person receiving their own area.
i had an idea to implement such a talk plugin that would work in a p2p way over yggdrasil, but my understanding is that current libpurple does not support showing characters one by one, but only complete messages.
another idea i have remembered: i know some people are insisting on using otr, instead of omemo.
OTR is abandonware, see this long thread on thunderbird discussing dropping it. 1909445 - Consider to turn off OTR chat encryption in Thunderbird
1 Like
and, would be good to be able to subscribe to xmpp feeds/microblogs.
These are feature ideas, not plugin ideas. Pidgin 2 should have never allowed XMPP features to only be implemented in plugins. They need the support of being in the main distribution and is precisely why we’re not making this possible in pidgin3/purple3 for any plugins.
ok, another thing i was wanting to implement, but as i understand, it is not possible with pidgin2, is a “talk” like communication plugin.
This should be trivial in purple3. The protocol plugin would just update the last message to have the updated contents. the message would be in a constant “edit” state, but there’s nothing wrong with that.
1 Like
It would be nifty if we could detect links to stuff like rick rolls and other things and warn the user. A plugin could scan a message for links and look for something like
https://www.youtube.com/watch?v=dQw4w9WgXcQand then highlight the message and give it a title like “WARNING: rick roll”.
Similar to this, it might be interesting to have something that can resolve shortened URLS. This should probably be a separate plugin as maintenance will be high with so many providers. Also privacy is a concern to, but maybe the plugin can let you choose which ones to resolve?
1 Like