Show HN: Open-source Telegram bot for music sharing
github.com
github.com
I'm curious about the specific use cases for this bot. Is the idea that it could be the primary place that a person stores and shares music with people? Or do you think it would be more short-term and focused - for example putting together a collection of tracks for some event or to share with a specific group of people? Why use this bot instead of something with, say, a traditional graphical UI?
I don't mean to sound negative or dubious, I'm just curious about the vision behind it.
I think for really basic functionality - like finding specific artists and tracks - the messaging UI is great. And if I could basically treat it like a friend with really good knowledge and taste in music and ask it put together a playlist along a specific theme or for a specific situation then the messaging UI would be a fantastic fit. However, for functionality in between (e.g. managing playlists, and tags, and discovering new music) then maybe typing a lot of text would be less convenient than a GUI. I dunno.
> Is the idea that it could be the primary place that a person stores and shares music with people?
That's the main idea, right. A global searchable catalog. Other use cases are harder because, as you mentioned, text is a pure UI for managing playlists. I'm thinking about turning it into a radio with recommendations based on likes. But for now, I just want people to fill the catalog with independent music.
I must admit, that the current generation of bots is quite dumb and we need to move towards natural languages and learning. I also don't think that bots are viable "app platforms". Bots should either be interfaces to bigger services or stand alone smart assistants.
BTW, I'm an "indipendent music maker myself (http://solyaris.altervista.org) and I debate since many years about copyright/copy-left realms. I unfortunately think your good idea, could be abused easly, as someone pointed out :( I'll feedback you later in different comment about this hot specific point.
Anyway, I fully agree with you, when you say that:
>Telegram is amazing platform and I'm looking forward for their next moves.
Absolutely! I think Telegram is moving really great designing the big picture "communication" architecture including: 1- p2p chats 2- groups & supergroups 3- channels 4- bots 5- bots integration in groups and channels
In my opinion this integration of bots INSIDE groups and channels (humans), open new services scenarios, not games! Instead service apps useful for people, in business/application scenarios A real revolution: integration of robots and humans services. I'm serious about it and my twitter microblog: www.twitter.com/solyarisoftware is about that. I wote some ideas about in my draft/raough doc here: https://github.com/solyaris/BOTServer/blob/master/wiki/servi...
> I must admit, that the current generation of bots is quite dumb and we need to move towards natural languages and learning.
I fully agree!
> I also don't think that bots are viable "app platforms". Bots should either be interfaces to bigger services or stand alone smart assistants.
Yes, but: I feel nowadays visual-paradigma/web-interface based/mobile apps are in many cases poor in suppluing real services. I'm basically perplex regarding nowadays glorification of (mobile) web interface as "THE way" (to communicate/to get services/make business). I feel instead that next generation(Telegram) bots could be instead a real revolution in man-machine interfaces for services apps: the (Telegram) chat as prevalent way to communicate for users (see very young people habits...). Now as a text-based chat, in a near future, I see phone-calls + video-calls as front-end (along with text-based chats).
What I mean, and I think I agree with you, is that a possible very interesting world is build-up "intelligent chatbots" machine-learning enabled, astep forward nowadays dumb bots that responds to basic /commands or enabled by some finite state machine dialogs (my project now).
What do you think ?
respect giorgio
> A real revolution: integration of robots and humans services
Exactly! And Facebook understands it, Facebook M is a pretty interesting project.
I had a look at the source to your aiotg package for writing such Telegram bots. IIUC, you run a single Python process using asyncio, and that uses coroutines to handle all requests (in and out).
What is your experience w.r.t. scalability in practice, for example with your music bot? (iow have you run into any issues with large numbers of users interacting with the bot?)
I have another bot (https://github.com/szastupov/whatisbot) which is a client to wikipedia and asyncio makes much more sense in this case.
In general, think asyncio is inevitable in current world of APIs and micro-services.
It's kind of a grey area and a subject for long debates, but as an artist and a fan, I believe there should be easy ways to share music. For example, Russian social network VK has allowed to do this for years and that's how a whole generation discovered new genres and artists. But this days, even VK has to comply with corporations (VK music is disabled on iOS). I'm just trying to replicate this user experience for Telegram.
Let's just see how it'll work. I don't mind removing and blacklisting some artists if necessary.
Now as I said in my previous comment, I'm me too an indipendent "artist" sharing my music in a compromise between free/no-free after long struggle with myself.
So MusicBot is great if used by artists/listeners fully aware about intellectual rights of posted contents. Long story. Generally, unfortunately, this is not the common case (awareness). The big risk I see, is that malicious (or simply ignorant/naif) users could post famous music (not necessarly good music), protected by copyrights. Boring Issues alla involving actors!
If I'm not wrong, quickly reading your beautiful synthetic python code, you store music in your server (as a MongoDB blob). ins't it ?
Smart. Superb I could say!
But a possible issue could be that you store music (possibly copyrighted) in your own server.
A possible workaround/proposal is to test your project, avoiding to store stuff in your server, but leaving digital contents in Telegram Servers! if I well remember, until now Telegram do not officially say when file will be purged after upload... Ok that's a "volatile contents" solution. Just an idea, maybe always interesting for sort of "auto-deleting" sahring, as secret messages (but could be wrong).
Another approach, could be, again to do not store anything in your server, no file upload/download, but just manage links to external repositories/specilized websites. An example ? just share links to youtube.com contents; in that way you "delgate" all copyrights possible issues to youtube censors ;-)
BTW, I quickly tested MusicBot looking for an artst and title, I noted that search functionality could be developed to understand better what user are looking for, but this is not a criticism of your excellent work, just a feature for a future implementation!
Thank again for sharing MusicBot respect giorgio
> If I'm not wrong, quickly reading your beautiful synthetic python code, you store music in your server (as a MongoDB blob). ins't it ?
Nope, the bot only stores track title, performer and id. Actual media is stored on Telegram servers.
> Just an idea, maybe always interesting for sort of "auto-deleting" sahring, as secret messages (but could be wrong).
Yes, I'm thinking about it.
> I noted that search functionality could be developed to understand better what user are looking for, but this is not a criticism of your excellent work, just a feature for a future implementation!
Sure, I'm open for any suggestions and criticism :) I'm thinking about how to improve it.
good idea ;-) BTW, do you have any recent news about Telegram decisions about uploaded files persistence on their server ? https://core.telegram.org/bots/faq#can-i-count-on-file-ids-t...
> For the moment, file_ids for your bot's outgoing files may be recycled after several thousand files have been sent. This may be changed in the future. Inbound file_ids can be treated as persistent.
About searching on MusicBot (using web interface: https://web.telegram.org/#/im?p=@MusicCatalogBot)
I noted that:
1. inserting an author name, by example:
Alice Coltrane
?! :-)
I got all tracks related to any "Alice", by example
Moby - Alice some other Cocteau Twins track, etc.
no track related really to "Alice Coltrane", that's probably because you just do an OR on your query, ok, clear.
2. in the web client, in result track list, song names appear truncated... by example I'm not able to read the Cocteau Twin complete title track, in the above example.
That's right, it's OR operation, but all you need to do to perform AND search is to specifically use quotes.
>in the web client, in result track list, song names appear truncated... by example I'm not able to read the Cocteau Twin complete title track, in the above example.
Unfortunately there is nothing I can do about it. I mean I could truncate it myself but the bot doesn't know anything about UI.
As far as I know, Telegram is really really open (at the moment) with really few limitations.
For me, this is a very important fact. yes, is a big (and debated) topic; Pavel Durov express many times the point. See: http://techcrunch.com/video/pavel-durov-of-telegram-whatsapp...
BTW, For another story, I pressed Telegram to know if I could or not use bot apss for commercial business.I puplished on my microblog homepage: twitter.com/solyarisoftware the answer I got by https://telegram.me/botsupport (BTW it's an helpdesk/support center, by humans, see typo :-))