Thanks for the feedback @JdB! Speckle 1.0 already supported authentication via Azure AD and GitHub, for 2.0 we’ll probably add Google Sign-In.
We’re also working on adding support for 3rd party apps so that people will be able to develop custom clients/apps just as you say. More on this in the near future!
2 Likes
late to the game 
the new structure seems like a good improvement! I think the “inbox” feed would help with SpeckleProject adoption.
Something that would be helpful is having a way of knowing if a stream is associated with the currently active account, since that seems to block any updates to the data sender (I might be wrong on that!). When we are doing troubleshooting, we find ourselves double checking if the account is associated with the stream by plugging in account management > list streams > panel to find the stream id. If the stream node was tinted or had a flag that indicated it was associated with a different account that would be handy 
2 Likes
Good point @haitheredavid! I personally struggled with the same issue in 1.0 :), permissions will be much improved in 2.0, and we’ll make sure to make it clear to whom a stream belongs to.
3 Likes
Hi everyone
To me the common approach used in Speckle 1.0 is that the source file essentially owned the stream, since users are usually prevented from selecting a stream on which to send data. This would encourage workflows that are based around one sender, multiple receivers at each hop, which minimises some complexity in data management.
With 2.0, the model would shift more towards a person or a group owning and collaborating on a stream, irrespective of which files are being used. Would this be on the mark?
This might open up some complexity with potentially competing sources sending data on the same stream.
However the git-esque paradigm of commits, branches and PRs sounds good to me.
After reading the post on transports: is it an idea for the UI indicate the projected speed of receiving on streams? That is, if the ids of a stream are mostly found on a local storage as opposed to on the server only.
Cheers
Nic
2 Likes
Hey Nic!
That sounds right on the money - we don’t really want streams to be tied to a single file. Part of the magic is receiving your data where you need it and collaborating with others! I can also envision this making it easier to create and manage multiple streams within a file. Working like this might facilitate smoother collaboration by separating out different types of data to different streams (eg by discipline or by some segment of the project) which would reduce the potential for conflicts. As you said, the improved versioning with commits and branches should also help with managing multiple people working on a single stream.
While this could make things seem more complicated, the redesigned UI will hopefully make the process more clear! A focus of the redesign is to make Speckle seem much less intimidating / complicated for someone trying it for the first time.
Re your last point, transports will be able to report their progress so a visual progress bar in the UI will not be a problem. You could also totally show if a transport is pulling locally or from a server 
1 Like