<dsc_>
XMPP does not actually a telepathy media/file-transfer channel
<dsc_>
XMPP does not actually open a telepathy media/file-transfer channel*
<dsc_>
its just a text message with a link
<dsc_>
I think I suggested before to HTTP HEAD it, if the mime is image, display it
<dsc_>
but afaik. Wizzup had some reservations
<dsc_>
and for video/music -> suggest to open it via the preferred application
Anasko has quit [Remote host closed the connection]
Anasko has joined #maemo-leste
joerg has quit [Read error: Connection reset by peer]
joerg has joined #maemo-leste
totalizator has quit [Ping timeout: 260 seconds]
bencoh has quit [Ping timeout: 260 seconds]
bencoh has joined #maemo-leste
GaryM_ has joined #maemo-leste
totalizator has joined #maemo-leste
Daanct12 has joined #maemo-leste
narodnik2 has quit [Ping timeout: 245 seconds]
narodnik has quit [Ping timeout: 276 seconds]
narodnik has joined #maemo-leste
narodnik2 has joined #maemo-leste
vectis has joined #maemo-leste
joerg has quit [Ping timeout: 255 seconds]
joerg has joined #maemo-leste
rhn has joined #maemo-leste
rhn has quit [Ping timeout: 252 seconds]
fmg_d4 has quit [Ping timeout: 252 seconds]
Anasko has quit [Read error: Connection reset by peer]
_fab has joined #maemo-leste
trix has quit [Server closed connection]
trix has joined #maemo-leste
fmg_d4 has joined #maemo-leste
<Wizzup>
yeah, strong reservations about doing HEAD without user interaction
rhn has joined #maemo-leste
<sicelo>
so middle ground is - show a placeholder, and pressing on it does the download (or provide a button)?
<sicelo>
i think Polari (Gnome's IRC client) does something similar
<Wizzup>
even just doing a head leaks information (ip, etc) and I don't think that should happen without user action
<freemangordon>
Wizzup: did you try libicd-network-wpasupplicant ?
<sicelo>
yeah, when there's link, Polari doesn't interact with it in any way. just shows some placeholder and lets it be :-)
<sicelo>
their implementation is a bit silly though, but at least it takes care of this concern
<Wizzup>
freemangordon: let me see if I got the latest version
<Wizzup>
I think I did, I don't think I had a lot of issues, I had one issue tryin to connect in the past few days, but nothing extremely repetitive as we used to have
<Wizzup>
so what kernel version is this, and does it match chimaera's where it works?
<inky>
Linux devuan-pinephone 6.1.15 #1 SMP Wed Jan 29 15:22:25 UTC 2025 aarch64 GNU/Linux
<inky>
i think same was on chimaera.
<inky>
also someone said camera doesn't work anymore.
<inky>
but i was wondering why - same kernel.
<inky>
perhaps we need to update the kernel.
<inky>
and it will be solved by itself.
<inky>
pull
<inky>
rebuild.
<inky>
can we do that? is that megi's orangepi branc?
<inky>
(it should be i believe)
<inky>
i am running 6.13.something on gentoo on emmc on PP
<Wizzup>
we should package a new kernel, is there an issue for it?
<inky>
github issue? should i create?
<Wizzup>
git.maemo.org issue pls ;p
<inky>
i can deal with kernel and test it if you want.
<inky>
just let me do that.
<Wizzup>
I just don't have the time/energy do some things, so it's very helpful to have other people step up like rafael2k did
<Wizzup>
great
<inky>
yes i suggested it like 5 times before.
<Wizzup>
I know
<Wizzup>
the above applies every time too :P
<inky>
so if you give me the kernel repo access, i may, first build the thing on pp as .deb package, test, then if it is ok, push to the repo and rebuild in jenkins.
<inky>
i guess kernel is also a deb package?
<inky>
yes it is.
<Wizzup>
the kernel repo is open, you can clone it and make local mods without write access
<Wizzup>
you can clone it and build it and see how things go
<inky>
oh great.
<Wizzup>
I actually think this is a great use case for our runners...
<Wizzup>
cc dsc
<Wizzup>
maybe we should try this first
<inky>
runners? what are runners?
narodnik has quit [Ping timeout: 260 seconds]
kiva has joined #maemo-leste
<Wizzup>
inky: sorry for the jargon
<Wizzup>
inky: we're working on setting up some continious integration on our forgejo so that you can push to a branch/commit and it will do a test build
<inky>
understand.
<Wizzup>
it won't upload it to the repos or anything yet, but it would test the build
<Wizzup>
you will need to make a maemo/daedalus-devel branch, and then pull in the latest mobian source and their patches, and then rebase our own patches against mobian and somehow make that work with the most horrendous thing ever: this debian tool for managing patches
<Wizzup>
so I think really all we need to do now is fix that quilt issue and we'd have a much more newer kernel
<kiva>
latest LTS kernel?
<Wizzup>
I don't know about the lts qualifier but let's get 6.12 going at least, then we can try again for the newer ones
<Wizzup>
I think the maemo quircks is really just making some things built in
meridion has quit [Server closed connection]
meridion has joined #maemo-leste
<inky>
okay okay, thank you, will deal with that. (though i noticed that 6.13 is much better than 6.12, lets say bluetooth didn't work well with 6.12 and is very stable with 6.13, but i'll do as you say)
<Wizzup>
we can go to 6.13 as well, but I think this will hopefully be an easier ask first.
_fab has quit [Ping timeout: 252 seconds]
freemangordon has quit [Remote host closed the connection]
<dsc_>
< Wizzup> sicelo: I would assume btw that xmpp sends some mime data along
<dsc_>
it does not
<Wizzup>
in telepathy as far as you can see, or on the protocol level?
<dsc_>
at least not for this particular XEP (xmpp extension)
<dsc_>
a far as I can see in Tp it is text, mimetype'd as such
<Wizzup>
yeah, I think Tp is not a good place to look for these things
<dsc_>
I know but its just a text message
<dsc_>
yes I will look at xmpp traffic
arno11 has quit [Quit: arno11]
<Wizzup>
it also depends on the xep's the client implements
<Wizzup>
(this is why we really need that qxmpp cm soon)
<dsc_>
whatever I did with prosody seems to be standard
<dsc_>
e.g. how most xmpp servers do it
<dsc_>
i dont know what other XEPs there are for actual p2p file sharing
<dsc_>
and to what extend clients support this
<Wizzup>
ok, I can't comment on your prosody setup at this point :)
<dsc_>
???
<Wizzup>
I'm just saying that it also depends on the client
<Wizzup>
not just the server
<Wizzup>
the client has to also support the right XEPs
<dsc_>
offers mechanism for HTTP PUT (file upload)
<dsc_>
then client is responsible for distributing this link to counterparty
<dsc_>
generally via a text message
<dsc_>
(correct me if I'm wrong)
<dsc_>
so in this flow, what shall Conversations do?
<dsc_>
in terms of displaying a link
<dsc_>
sicelo's idea of a placeholder ?
<dsc_>
ill do that
kiva has quit [Quit: Client closed]
<Wizzup>
I am not sure if that makes sense if it is just a lnk
<Wizzup>
it depends on what you want to do with it I guess
<sicelo>
idea is that the user can now decide if they want to follow/download whatever that thing is, without auto-fetching for them. if we wanted to go one step further, could even popup that warning "Warning: you are going to an external link. There may be dragons" :p
<Wizzup>
I think it's worth thinking this through a bit before implementing fully tbh
<Wizzup>
this touches on many things, including file downloads and where to place them\
<dsc_>
sicelo: thing is though, when to display such a widget
<dsc_>
"when we receive a link"
<dsc_>
a link could be pointing to a webpage
<dsc_>
or an image
<sicelo>
when trying to access it
<dsc_>
i know about content-type, my question is do we then generate such a preview widget for every link
<Wizzup>
right, but do you open a browser then, or do you open OMP? or photo viewer?
<dsc_>
Wizzup: right
<Wizzup>
or does conversations do a HEAD and then decide how to route it
<dsc_>
im talking about the widget that will ask the user for a click to investigate (sending out a HEAD)
arno11 has joined #maemo-leste
<Wizzup>
yes, so I think user interaction can definitely trigger the HEAD
<Wizzup>
I am just not sure about always doing the HEAD without any interaction upon receiving
<Wizzup>
but there's also xdg-open and other questions, and where to download the file
<Wizzup>
for example, do we download a mp3 and then issue xdg-open, or do we issue xdg-open on the link
<dsc_>
we are def. not going to send a HEAD for every thing, at least not by default
<dsc_>
because it leaks
<dsc_>
Wizzup: even more fun; I think attachments should go into rtcom db
<dsc_>
maybe I am misremembering though
<Wizzup>
yeah... I am not sure if I liked that approach from nokia
narodnik has joined #maemo-leste
<sicelo>
yes, when the user presses, that's when HEAD is done. at least i do something similar on whatsapp - because i'm heavily capped, i've set it to open media only when i explicitly want it to
<dsc_>
sicelo: to verify; this must then happen for every link
<dsc_>
because beforehand we dont know what that link could be
<sicelo>
and yes, no HEAD before user interaction, and we can open links internally, not needing jib (or other browser)
<sicelo>
dsc_: yes, every link
<dsc_>
alright, so if it turns out its text/html
<dsc_>
what does the preview widget turn into
<sicelo>
anyhow, this can be honed properly ... was just throwing a quick suggestion (and i'm not UX guy, which is also an important consideration)
<dsc_>
sicelo: no no, you *must* also now offer your insights/suggestions :)
<sicelo>
i guess for simplicity, we don't need to do preview widgets. just report the doc type, and let user choose what they want to do (open in Conversations, if it has a way to do so, Save, or open externally)
<dsc_>
ah yeah, good idea
<dsc_>
ok
<dsc_>
Wizzup: as for actual Tp file sharing stuff, would you recommend I look up the relevant XEP for that or perhaps try something like Matrix
<sicelo>
could also have a setting btw, for user to configure their auto-download options ... because others may not really care about the information exposure from HEAD. at least with a configuration item that defaults to no-HEAD, the user can make a decision to be always applied
<dsc_>
sicelo: right
<Wizzup>
what does matrix do
<Wizzup>
sicelo: I mean it's an instant ip leak essentially
<dsc_>
im just trying to think of a protocol that 1) we have a Tp CM for 2) does direct file-sharing
<dsc_>
so I can implement the Tp filesharing channel
<dsc_>
not sure what matrix does
<dsc_>
likely similar to xmpp :P
<dsc_>
with the http upload
<Wizzup>
oh, I see
<sicelo>
Wizzup: the HEAD? again, it would happen automatically *only* if the user has configured Conversations for that. otherwise it defaults to the prompt
<Wizzup>
sorry, I don't actually know what would be best for this, ideally we put a bit of work in the qxmpp one, we were so close
<Wizzup>
tp-gabble does not support http upload
<Wizzup>
sicelo: yes, but the HEAD does expose the ip
<dsc_>
Wizzup: even with qxmpp, I wonder if other chat clients support p2p filesharing
<sicelo>
yes, the user has chosen to expose it by then, no?
<dsc_>
e.g. my irssi does not do DCC
<dsc_>
(disabled)
<dsc_>
also I can imagine a lot of servers do not setup STUN/TURN
<dsc_>
(I am guessing this is needed)
<dsc_>
anyway we can think about it later
<Wizzup>
dsc_: why p2p in particular?
<dsc_>
Wizzup: I'm just not sure at this point what actually uses Telepathy's fileshare channel (as opposed to TextChannel)
<Wizzup>
for us, probably nothing right now
<dsc_>
FileTransfer*
<Wizzup>
honestly I'd not bother until we have a cm that does it well
<Wizzup>
maybe with the telegram plugin it could work, I didn't check
<Wizzup>
they clearly download something there already
<dsc_>
they also generate a thumbnail :P in our case have to be careful not the display some 4096x4096 picture
<sicelo>
yeah we can leave out the 'preview' part, of course :-)
<dsc_>
btw, a bit unrelated
<dsc_>
last night I was reading the ircv3 specs
<dsc_>
and its pretty cool
<dsc_>
brb
<sicelo>
but not a lot of servers implement it (although iirc libera does)
narodnik has quit [Ping timeout: 252 seconds]
<arno11>
Wizzup: @tdlib being our best bet, at least media sharing (audio, img, file) works pretty well with our tdlib plugin through pidgin
<Wizzup>
yeah I think so too
<Wizzup>
cc dsc_
<arno11>
dsc_: our tdlib is probably easier to deal with (vs xmpp)
pere has quit [Ping timeout: 245 seconds]
Daanct12 has quit [Quit: WeeChat 4.7.0]
<Wizzup>
inky: did you take a look yet? otherwise I can -try- to fix the quilt thing
<Wizzup>
I think we just move some of our patches to the git branch and not deal with quilt
fmg_d4 has joined #maemo-leste
narodnik has joined #maemo-leste
narodnik has quit [Ping timeout: 255 seconds]
narodnik has joined #maemo-leste
<arno11>
Wizzup: dsc_: yeah i'm already able to open file received from tdlib/conversations
<arno11>
if i receive a file, conversations shows an empty txt msg but the file is automatically downloaded in .local/share/tdlib/
<Wizzup>
arno11: oh really?
<arno11>
yes :)
<Wizzup>
well, we're definitely lacking something on the tp-haze side I think
<Wizzup>
but funny that tdlib already does it for us
<arno11>
:D true
<arno11>
let's try audio and video
<arno11>
audio is not downloaded apparently
<Wizzup>
well, tp-haze doesn't register the interfaces for file transfer in any case
<Wizzup>
so there's no chance of it working well for us currently
<Wizzup>
we just need to work on our connection managers unfortunately
<arno11>
okay
<Wizzup>
ironically enough it's not impossible that irc might actually be the best way to test
<Wizzup>
tp-idle does support message transfers
<Wizzup>
at least... I think?
<Wizzup>
maybe not... ugh
<arno11>
maybe, really don't know
<arno11>
so yeah, with tdlib, only imgs are automatically downloaded (with original resolution)
<Wizzup>
this is probably configurable
<Wizzup>
I think dsc is just looking for ANY cm that can do file transfers :D
<Wizzup>
honestly I think we should fix up the qxmpp one and make it work well, we were very close
<arno11>
:D
<arno11>
ok
<arno11>
@Wizzup: this is probably configurable, pretty sure it is yeah: i.e pidgin show photos automatically but other files need a click on the msg
<arno11>
really cool: if i take and send photo from my andro tg to n900 tdlib, it takes 2 sec to appear in .local/share/tdlib. if i delete the photo from andro tg and ask to remove it in n900, it works as well :D
<Wizzup>
also kind of freaky
<arno11>
it's the way it works in android/ios app
<arno11>
i mean for sending/deleting
<Wizzup>
sure, it's not cool that some other device can trigger file deletions imo :D
<arno11>
100% agree with you !
<arno11>
but it can prevent accidental img sending. could be useful sometimes lol
arno11 has quit [Quit: arno11]
narodnik has quit [Quit: WeeChat 4.7.0]
<sicelo>
Wizzup: that's a nice feature in Telegram actually (imo)
<sicelo>
WA has it now too, but it leaves a placeholder, and you can't delete beyond a certain time period
<Wizzup>
I'm too old to believe that once I've sent a file to people that I can actually delete it from their machines
<Wizzup>
maybe the snapchat generation things this is the case :)
Twig has joined #maemo-leste
_fab has joined #maemo-leste
narodnik has joined #maemo-leste
<sicelo>
heh, well obviously unless the user makes a copy first. as arno said, it's very useful for if you sent something through by mistake.
rhn has joined #maemo-leste
rhn has quit [Read error: Connection reset by peer]
rhn has joined #maemo-leste
rhn_mk1 has joined #maemo-leste
rhn has quit [Ping timeout: 252 seconds]
freemangordon has joined #maemo-leste
Pali has quit [Quit: Pali]
kiva has joined #maemo-leste
<kiva>
delete message from your device by remote device is so frightening...Think situation when somebody miss use remote device.
<sicelo>
it only deletes messages between the two of you.
<kiva>
..have to trust that nobody hack the devices.
<kiva>
Anyway if you do that external link support then MMS support is quite near...basically MMS message has link to operators server to file to download.
<kiva>
This time it is enough for me to know that somebody had tried send MMS..I get MMSs from two people at weekend, luckily I has N900 with Maemo5 with fMMS in use.
<dsc_>
arno11: perhaps its weird that tdlib auto-saves incoming files because it should leave that to the client
<dsc_>
CM is facilitating the connection
<dsc_>
client should determine if it handles files or not
<dsc_>
but I have yet to look into tdlib
pere has joined #maemo-leste
arno11 has joined #maemo-leste
<arno11>
dsc_: @auto-saves, it only happens with photos
<arno11>
i.e in pidgin, photos appear directly in chat window without any user click
<arno11>
other files need client/user 'authorization'
<dsc_>
arno11: sure, but I mean from a Telepathy architecture perspective
<dsc_>
a connection manager facilitates connections
<dsc_>
for clients
<arno11>
okay
<dsc_>
:P
<inky>
> inky: did you take a look yet? otherwise I can -try- to fix the quilt thing
<inky>
no sorry. Tuesday is hardest day with lots of calls.
kiva has quit [Quit: gcc-ia16]
xmn has joined #maemo-leste
mdz has joined #maemo-leste
arno11 has quit [Ping timeout: 252 seconds]
freemangordon has quit [Quit: Leaving.]
freemangordon has joined #maemo-leste
<freemangordon>
dsc_: actually CM may provide a message part with appropriate mime type, however, I agree that it is the client that shall decide what to do
<dsc_>
freemangordon: maybe CM needs to save it temporarily while offering the file to clients, not sure
rhn_mk1 has quit [Ping timeout: 260 seconds]
<freemangordon>
no, why should it do so if it provides the binary data with the appropriate mime type
<freemangordon>
like, it is perfectly ok to provide message part with image/jpeg mime type
<dsc_>
with part you mean multipart?
<dsc_>
i was thinking about big files maybe
<dsc_>
yeah, im not sure why CM would save the file
_fab has quit [Ping timeout: 252 seconds]
<freemangordon>
exactly, it is not CM's job to do that, IIUC
<freemangordon>
sure, it may provide url to the client
arno11 has joined #maemo-leste
<freemangordon>
but downloading files should not be CM's job, if I understand TP architecture properly
<freemangordon>
and yes, I mean multipart messages